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 jilles@rendo.dekooi.nl -----Oorspronkelijk bericht----- Van: Ray Gardiner Aan: PICLIST@MITVMA.MIT.EDU Datum: donderdag 28 september 2000 4:05 Onderwerp: Re: [PIC]: COMPLETELY PERPLEXED! (I usually think it's me, but...) >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 >>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 mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST > >Ray Gardiner ray@dsp.com.au >mail from: dsp systems > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST > > -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu