16F1829 Problem Reading RA2 Input

[Ian Rogers]

Have you noticed the Status register!!!! The carry bit is set in one but not in the other... This makes subtraction and addition susceptible to errors... Clear the carry before any maths...

 

[jpanhalt]

Of course, STATUS is wrong in the ICD3 simulation, but why? Even without a carry bit ((looking at the lower byte), 5 -1 = 4, not 5. This is at least the second instance when ICD3 doesn't seem to follow the instructions in the code, and there is no hint why that I can find.

I have read that hardware breakpoints are handled like interrupts in the code in contrast to software breakpoints that simply pause execution. On a fuzzy theory that such an interrupt might affect execution with a branch, such as a BTFSS, I introduced several NOP's at places where I wanted a hardware breakpoint and put the breakpoints on a NOP. That did not help.

At this point, I plan to go back to MPLab SIM, which is a PITA when you have various interrupt flags to poll, but it is quicker than spending a week trying to get one section of code to run in ICD3 simulation. Before I do that, though, I think I will try my PK3. It also gives 3 hardware breakpoints. I will try to get to it today. I am not optimistic the results will be any different.

John

 

[Ian Rogers]

If you need to sim it fully... I can just do that in ISIS.. I already have it all set up.... I just need to stick a terminal onto the schematic..

 

[jpanhalt]

UPDATE
Limited progress. Tried PK3; however, because of its limited power supply, I disabled the sensor/encoder, removed its power line (target was powered by debugger), and loaded the four registers (CountH/L and SPI_H/L). It worked and the math was all correct.

Then replaced PK3 with ICD3 under the same conditions, and it also worked. Attached the sensor/encoder chip, but still used the loaded registers. Still worked. When I went back to using real data from the encoder, got the same problem as before. The mystery is that the numbers I loaded into the four registers are the same as what the encoder is sending. Moreover, those numbers appear in the watch window at a breakpoint set just before processing for the stepper. No interrupts are enabled.

Next step is to bring up a separate 5-V supply and power the targets from that. Will also use the PK3 as it is quicker. That is, it is ready to debug just after programming; whereas, the ICD3 needs to go through a read cycle after programming.

John

 

[jpanhalt]

Ian, Thank you for the offer. But I am making progress, albeit slowly. Give me a couple of more days to bang my head. I can't leave it not knowing why, at least not yet.

John

 

[Ian Rogers]

One little thing that bothers me... CountH and CountL are never initialized.... If I turn on random ram initialization then the 16bit counter has 0x26b as a start value!! is this correct? This could be anything in a real device..

 

[jpanhalt]

SOLVED

I have a little register initialization scheme that I adapt as appropriate to clear General Purpose Ram and Common Ram. I left it out from debugging as I am watching the registers and may not want them all cleared. In this case, CountH/L will be seeded with the "zero" position. That wasn't the problem here. But I did find it.

I try to track memory bank changes and put registers accessed from other than Bank0 in Common RAM or the bank that register is accessed from (rare). Well, in this case I screwed up. SPI_H/L were in Common RAM, but for some unknown reason I put CountH/L in GP RAM. I think that mistake resulted from when I moved from just wiggling the stepper to actually using it. The more I looked at it, the less I saw. The epiphany came when I had everything working well using seeded registers. And as previously experienced, when I used values captured by the USART, the math failed. So, I tested by putting some of the register values from seeds and some from the USART. With CountH/L seeded and SPI_H/L captured , it worked. Voila. I feel like a fool, but one is always learning. I could blame it on 16-year-old Lagavulin, but she wasn't involved. I may enjoy some tonight, though.

Sorry for causing you all of the unnecessary effort. Again, many thanks for the effort and offer.

John

;Initialize (clear) RAM: GPR(0x20 - 0x35) and Common Ram
     CLRF      FSR0H               ;                                       |B0
     MOVLW     0x20                ;                                       |B0                                                                         
     MOVWF     FSR0                ;                                       |B0
Clr_GPR   
     CLRF      INDF0               ;                                       |B0
     INCF      FSR0
     MOVLW     0x35                ;                                       |B0
     XORWF     FSR0,w              ;                                       |B0
     BTFSS     STATUS,z            ;                                       |B0
     GOTO      Clr_GPR             ;                                       |B0
     MOVLW     0x70                ;                                       |B0
     MOVWF     FSR0
Clr_CRAM
     CLRF      INDF0               ;                                       |B0
     INCF      FSR0
     MOVLW     0x7F                ;                                       |B0
     XORWF     FSR0,w              ;                                       |B0     
     BTFSS     STATUS,z            ;                                       |B0
     GOTO      Clr_CRAM            ;                                       |B0
     NOP

 

[Ian Rogers]

Makes the day!! Now I need to solve my little puzzle! Cheers for the update.. I'm a speyside lover so a good Macallan 12 will suffice...

 

[jpanhalt]

Wish I could help you, but I know I can't. As for Macallan, way back when, I heard that 1982 was special. I now have just one bottle left that is being saved for a very special occasion. I do like a little more smoke in mine, though. To me, Lagavulin is the perfect compromise. Have a great evening.

John

 

[NorthGuy]

Watching RA2 and RA5 is pointless. They don't contain the valid address, rather the number of the bit. RA2 is simply 2 and reads at address 2, which is PCL. Since it's 6C, the "ICD3" case definitely uses a bigger program than the one you use on SIM, which explains the difference in results. My guess is that the bank (BSR) has gone wrong, but might be something else. I would suggest putting the BSR on the watch list.

May I also suggest using BRA instead of GOTO for local stuff because it eliminates paging problems.

 

[jpanhalt]

Actually what is being polled is PortA,2:

RA2 was just a shortcut for here. "RA2" appears as a symbol that can be watched, but I didn't have a clue what the 8-bit value meant for that symbol. Nice to know it is PCL. I principally watch PortA.

Thanks for the suggestion for using BRA.

New but related question:

I have found behavior of ICD3 to be different than PK3. When doing hardware debugging with PK3, all I have to do is build and program. The PK3 then works fine. I can also use the Reset button, which works as expected. With the ICD3, I need to build, program and read to debug. If one tries to debug without reading, you get an error to the effect that the target is not ready. Moreover, Reset does not work and gives another error message ("failed"). I use Read to effectively reset. Overall, using ICD3 is a lot slower.

Is that behavior typical and is there a known reason for it?

John

 

[Ian Rogers]

I don't have ICD3.... As you know I use a sim, but I have on occasion use PK3.. I was a bit disgruntled as there are only a couple of breakpoints available ( This was on a PIC32 )... MikroC pro for PIC32 has a better ICD ( microprog ) and full debugging is available..

I think I would be lost without ISIS...

 

[JimB]

Speyside
Macallan
Lagavulin

Sounds like a day out in the countryside for me!

JimB

 

[Ian Rogers]

Yeah! Back on whisky!!!

 

[NorthGuy]

I found ICD3 to be more picky than PICKit3 to the electrical connections. PICKit3 always works, but ICD3 sometimes fails where PICKit3 worked fine.

 

[jpanhalt]

Is it typical that I have to read before debugging with the ICD3? My connections are the cables from Microchip that go to a relatively new breadboard with very short wires to the chip. The ICSP pins are not used for anything else. MCLR has only a 33K pull-up resistor and no capacitor on it. Power to the target is from a USB separate port, but when I powered from ICD3, behavior was the same.

John

 

[NorthGuy]

I've never had to read mine to be able to debug. I usually get the same error as you if I forgot to program it, programmed it with release build instead of debug or did something of that sort. If I'm not mistaken, the only difference between programming and debugging is that during programming PGC (ICSPCLK) is driven by ICD3 while during debugging it's driven by PIC.

 

[jpanhalt]

Thanks. The behavior I noted was definitely in Debug mode and the chip was programmed. Looks like a call to Microchip tech service may be in order.

John