Post by thread:[PIC]: COMPLETELY PERPLEXED! (I usually think it's

I am writing a couple of thousand lines of code for 16c877 using the ICD. Well into the project, I have encountered some very strange problems involving data memory variables. I have defined a list of them starting at 0x0020. At some places in my program, I cannot seem to write to them, even though I THINK I have taken care with respect to the proper bank and page definitions. For instance, in this case: calib nop banksel msg_nbr movlw .65 ;table address movwf msg_nbr movwf sp1 The literal in w WILL be written to msg_nbr, but NOT to sp1. FWIW, msg_nbr is assembled at 0x0024 and sp1 is at 0x003D (using CBLOCK/ENDC.) Curiously, if I reverse the placement of the variable names, the result reverses also. That is, if sp1 assembles at 0x0024 and msg_nbr is assembled at 0x003D, the program fragment shown will write to sp1 but not to msg_nbr. This seems to suggest that there is something wrong with the memory location itself, but I have swapped physical '877 devices and gotten the same result. The final blow came when I discovered, by single-stepping ICD, that sometimes even "BSF flags1,0" would not set the designated bit. (flags1 is assembled at 0x0020) I should add that all of this code is on page 0, (PCLATH is at 0x00) and the RP1:RP0 bits in STATUS say I am looking at data memory bank 0. Has anyone seen anything like this before? I usually think its just my oversight (and it usually is,) but this time I'm not so sure. I am completely perplexed by this, and am simply stopped in my tracks. I am hoping some of you brilliant and more experienced folk out there have a suggestion or two for me. Thanks once again for your invaluable assistance. Foster -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use spam_OUTlistservTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST

Hi Foster, Persistence is the most valuable asset to have at this point. Here is a (partial) checklist. 1. Dont' assume anything. 2. Check the assembler list file to verify that the assembler is producing what you expect. Watch for page boundary crossing. 3. Watch out for interrupt routines nesting too deep. 4. Check carefully where you use FSR to write indirectly to memory that you aren't inadvertently overwriting other memory. 5. What is the macro expansion for banksel? 6. Check for things like "movlw sp1" when you really meant "movf sp1,w".. Others, will add more things to look for. Let us all know what you find. {Quote hidden}>I am writing a couple of thousand lines of code for 16c877 using the ICD. >Well into the project, I have encountered some very strange problems >involving data memory variables. I have defined a list of them starting at >0x0020. At some places in my program, I cannot seem to write to them, even >though I THINK I have taken care with respect to the proper bank and page >definitions. For instance, in this case: > >calib nop > banksel msg_nbr > movlw .65 ;table address > movwf msg_nbr > movwf sp1 > >The literal in w WILL be written to msg_nbr, but NOT to sp1. > >FWIW, msg_nbr is assembled at 0x0024 and sp1 is at 0x003D (using >CBLOCK/ENDC.) Curiously, if I reverse the placement of the variable names, >the result reverses also. That is, if sp1 assembles at 0x0024 and msg_nbr >is assembled at 0x003D, the program fragment shown will write to sp1 but not >to msg_nbr. This seems to suggest that there is something wrong with the >memory location itself, but I have swapped physical '877 devices and gotten >the same result. > >The final blow came when I discovered, by single-stepping ICD, that >sometimes even "BSF flags1,0" would not set the designated bit. (flags1 is >assembled at 0x0020) > >I should add that all of this code is on page 0, (PCLATH is at 0x00) and the >RP1:RP0 bits in STATUS say I am looking at data memory bank 0. > >Has anyone seen anything like this before? I usually think its just my >oversight (and it usually is,) but this time I'm not so sure. > >I am completely perplexed by this, and am simply stopped in my tracks. I am >hoping some of you brilliant and more experienced folk out there have a >suggestion or two for me. > >Thanks once again for your invaluable assistance. > > Foster > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >use .....listservKILLspam@spam@mitvma.mit.edu?body=SET%20PICList%20DIGEST Ray Gardiner rayKILLspamdsp.com.au mail from: dsp systems -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use .....listservKILLspam.....mitvma.mit.edu?body=SET%20PICList%20DIGEST

adastra wrote: {Quote hidden}> > I am writing a couple of thousand lines of code for 16c877 using the ICD. > Well into the project, I have encountered some very strange problems > involving data memory variables. I have defined a list of them starting at > 0x0020. At some places in my program, I cannot seem to write to them, even > though I THINK I have taken care with respect to the proper bank and page > definitions. For instance, in this case: > > calib nop > banksel msg_nbr > movlw .65 ;table address > movwf msg_nbr > movwf sp1 > > The literal in w WILL be written to msg_nbr, but NOT to sp1. > > FWIW, msg_nbr is assembled at 0x0024 and sp1 is at 0x003D (using > CBLOCK/ENDC.) Curiously, if I reverse the placement of the variable names, > the result reverses also. The easiest check is to look at the *.lst file to make sure of the HEX code produced. If it is correct and the bank select bit is right, then the ICD must(?) be at fault. 00D4 00A4 00342 movwf msg_nbr 00D5 00BD 00343 movwf spl Do you have both 'sp1' labels and 'spl' labels. They look the same, but they aren't. Is this actually doing what you think "banksel msg_nbr" Try using this... calib nop ; banksel msg_nbr clrf STATUS movlw .65 ;table address movwf msg_nbr movwf sp1 If it now works, the banksel is somehow at fault. (unlikely) If it still doesn't work, then good, msg_nbr or spl is defined wrong. I actually got caught with a similar problem yesterday. I accidently deleted a RAM definition, and while writing the upteenth code line I used the same name as a label for a GOTO. It assembles and works ok, but the results are weird. Prior to that I spent 5 frustrating hours trying to find a bug that turned out to be a BTFSC instruction that was supposed to be a BTFSS. After awhile you begin to think that that little PIC has somehow come to life and is out to get you. What you have to remember is the micro will do exactly what you tell it to, not what you want it to. Take a break for an hour and go for a brisk walk. You'd be amazed at the bugs that suddenly jump out at you on your return. I must remember to take that advice myself ;-) -- Best regards Tony ICmicro's http://www.picnpoke.com EraseMEsalesspam_OUTTakeThisOuTpicnpoke.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use listservspam_OUTmitvma.mit.edu?body=SET%20PICList%20DIGEST

Be sure to have watches in ICD for those variables so that they are updated in single-step! (or choose to update all registers + fsr, etc in the ICD) (does not explain the 'reverse statements, reversed outcome' thingy... but this is important i think). Regards, Jilles Oldenbeuving @spam@jillesKILLspamrendo.dekooi.nl -----Oorspronkelijk bericht----- Van: Ray Gardiner <KILLspamrayKILLspamDSP.COM.AU> Aan: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU <spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU> Datum: donderdag 28 september 2000 4:05 Onderwerp: Re: [PIC]: COMPLETELY PERPLEXED! (I usually think it's me, but...) {Quote hidden}>Hi Foster, > >Persistence is the most valuable asset to have at this point. >Here is a (partial) checklist. > >1. Dont' assume anything. > >2. Check the assembler list file to verify that the assembler is > producing what you expect. Watch for page boundary crossing. > >3. Watch out for interrupt routines nesting too deep. > >4. Check carefully where you use FSR to write indirectly to memory that > you aren't inadvertently overwriting other memory. > >5. What is the macro expansion for banksel? > >6. Check for things like "movlw sp1" when you really meant "movf sp1,w".. > >Others, will add more things to look for. Let us all know what you >find. > > >>I am writing a couple of thousand lines of code for 16c877 using the ICD. >>Well into the project, I have encountered some very strange problems >>involving data memory variables. I have defined a list of them starting at >>0x0020. At some places in my program, I cannot seem to write to them, even {Quote hidden}>>though I THINK I have taken care with respect to the proper bank and page >>definitions. For instance, in this case: >> >>calib nop >> banksel msg_nbr >> movlw .65 ;table address >> movwf msg_nbr >> movwf sp1 >> >>The literal in w WILL be written to msg_nbr, but NOT to sp1. >> >>FWIW, msg_nbr is assembled at 0x0024 and sp1 is at 0x003D (using >>CBLOCK/ENDC.) Curiously, if I reverse the placement of the variable names, >>the result reverses also. That is, if sp1 assembles at 0x0024 and msg_nbr >>is assembled at 0x003D, the program fragment shown will write to sp1 but not >>to msg_nbr. This seems to suggest that there is something wrong with the >>memory location itself, but I have swapped physical '877 devices and gotten >>the same result. >> >>The final blow came when I discovered, by single-stepping ICD, that >>sometimes even "BSF flags1,0" would not set the designated bit. (flags1 is >>assembled at 0x0020) >> >>I should add that all of this code is on page 0, (PCLATH is at 0x00) and the >>RP1:RP0 bits in STATUS say I am looking at data memory bank 0. >> >>Has anyone seen anything like this before? I usually think its just my >>oversight (and it usually is,) but this time I'm not so sure. >> >>I am completely perplexed by this, and am simply stopped in my tracks. I am {Quote hidden}>>hoping some of you brilliant and more experienced folk out there have a >>suggestion or two for me. >> >>Thanks once again for your invaluable assistance. >> >> Foster >> >>-- >>http://www.piclist.com#nomail Going offline? Don't AutoReply us! >>use TakeThisOuTlistservEraseMEspam_OUTmitvma.mit.edu?body=SET%20PICList%20DIGEST > >Ray Gardiner RemoveMErayTakeThisOuTdsp.com.au >mail from: dsp systems > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >use listservEraseME.....mitvma.mit.edu?body=SET%20PICList%20DIGEST > > -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestmitvma.mit.edu

Ray Gardiner wrote: > > Hi Foster, > > Persistence is the most valuable asset to have at this point. > Here is a (partial) checklist. > > 1. Dont' assume anything. > > 2. Check the assembler list file to verify that the assembler is > producing what you expect. Watch for page boundary crossing. > > 3. Watch out for interrupt routines nesting too deep. > > 4. Check carefully where you use FSR to write indirectly to memory that > you aren't inadvertently overwriting other memory. > 4.1 This had me by the throat before: Make sure you don't write to the memory ( with ie FSR) used by ICD. You want to see the PIC doing weird and wonderfull things, try mucking with the ICD RAM. > 5. What is the macro expansion for banksel? > > 6. Check for things like "movlw sp1" when you really meant "movf sp1,w".. > Quentin -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu

Well, here's how it turned out: We have had this system running around the clock for quite a while. During the course of system development, we have many times turned off the "target system", which also removes power from the ICD. However, it didn't occur to me to re-boot the host PC as a solution to this problem. After posting to the list last night, I turned EVERYTHING off and went home for the night in a state of great frustration. When I turned it all on this morning, everything was back to normal. I appreciate the helpful suggestions, I only wish I had thought of re-booting the host before posting. Still, there may be some general value in the observation that there seems to be some sort of RAM image of the target PIC held in the PC memory which can apparently get corrupted somehow with very confusing results. Once again. thanks to everyone for your time and attention. Best regards, Foster > {Original Message removed}