Post by thread:[PIC]:incf,f

I have two incf instructions: movf baasaadress,w movwf FSR incf FSR,f incf FSR,f In simulator everything is well, but in action it seems that FSR is increased only once. Is it possible that two incf instructions in succession can result only one increase? -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> I have two incf instructions: > movf baasaadress,w > movwf FSR > incf FSR,f > incf FSR,f > > In simulator everything is well, but in action it seems that FSR is > increased only once. Is it possible that two incf instructions in > succession can result only one increase? So unlikely it's not worth considering. There is something else wrong. Until you believe that you won't be able to find and fix it. Is the bank set properly when fetching BAASAADRESS? ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

pic microcontroller discussion list <> wrote on Tuesday, July 08, 2003 9:40 PM: > I have two incf instructions: > movf baasaadress,w > movwf FSR > incf FSR,f > incf FSR,f > > In simulator everything is well, but in action it seems that FSR is > increased only once. Is it possible that two incf instructions in > succession can result only one increase? I doubt it. You could easily check though, by replacing the above code with movf baasaadress,w addlw d'2' movwf FSR I would suspect the fault is somewhere else in your code, but the above would show that up (and is one cycle shorter, and lets you check for overflows once instead of twice!). Next, have a look at the .LST file, and check the assembled addresses are as you expected. Nigel -- Nigel Orr, Design Engineer spam_OUTnigelTakeThisOuTaxoninstruments.co.uk Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT Tel:+44 1467 622332 Fax:+44 1467 625235 http://www.axoninstruments.co.uk -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Have to agree with Olin and Nigel.....I've done this many a time and its always worked. IMHO, the best way to debug is with the ICD, just watch the registers and step thru it. Sometimes the most obvious errors are made totally clear when you single step. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

To be clear, Olin is correct in that the PIC would *never* skip the second INCF (barring, of course, a defective PIC). What might be confusing here is that his question about the bank setting is a separate question and whether or not it is correctly set does not alter the operation of the consectutive INCF instructions. (It may indeed increment an incorrect value, from that expected by what intended the program to do, but would in no way modify the operation of the execution of the instruction sequence.) Douglas Wood Software Engineer .....dbwoodKILLspam@spam@kc.rr.com ICQ#: 143841506 Home of the EPICIS Development System for the PIC http://epicis.piclist.com {Original Message removed}

"Olin Lathrop" <olin_piclistKILLspamEMBEDINC.COM> wrote: > > I have two incf instructions: > > movf baasaadress,w > > movwf FSR > > incf FSR,f > > incf FSR,f > > > > In simulator everything is well, but in action it seems that FSR > > is increased only once. Is it possible that two incf instructions > > in succession can result only one increase? > > So unlikely it's not worth considering. There is something else > wrong. Until you believe that you won't be able to find and fix it. > Is the bank set properly when fetching BAASAADRESS? I'd suspect incomplete simulation, not a bank-setting issue. I imagine that the code's being simulated by manually putting a number in baasaadress, then running the four lines above. Maybe some small portion of the code above this four-line fragment is being simulated, but in any case, a complete simulation from power-on reset isn't being performed. In the real system, of course, there are thousands or millions of instructions that execute before these four. If I had to guess at the root cause of the problem, I'd say that at the start of these four lines, baasaadress already contains a value that's one less than expected, and that if a true simulation from power-up were performed, the conclusion would not be "in simulator everything is well." -Andy === Andrew Warren -- .....aiwKILLspam.....cypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I made some tests and it seem that incf instructions are not the cause of bad funtioning. The chip is OK, i think. But I use it to drive stepper motors and baasaadress gets its value via serial interface from parallel port. Maybe EMI corrupt RAM-memory where baasaadress is located. I know very little about electronics. But maybe there are bug in my code that I can't see in simulator. Anyway, thanks for your comments. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> I made some tests and it seem that incf instructions are not the cause > of bad funtioning. The chip is OK, i think. Yeah, we already knew that. > But I use it to drive > stepper motors and baasaadress gets its value via serial interface from > parallel port. That presents lots of opportunity for something to go wrong. How have you verified that BAASAADRESS is correct? You can't fully test this with the simulator. You could do this with an ICD or ICE, or have it send debug information to a serial port. > Maybe EMI corrupt RAM-memory where baasaadress is located. Groan! I thought you were past the voodoo debugging. Stay after school and write on the blackboard 100 times "There is nothing wrong with the chip, my program has a bug." > I know very little about electronics. But maybe there are bug > in my code Gee, d'ya think!? > that I can't see in simulator. That's possible, especially when talking to real world signals. The ICD or ICE would be the preferred tool to find this bug, but you can probably simulate it too with a little work. If you are using the parallel slave port, you can at least simulate receiving bytes at the register level. Otherwise you can simulate all the I/O lines with a pin stimulus file. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body