Yet again, I find myself in the unique situation where I actually want to
use the ICD as an actual debugger, and enabling it fixes the problem. As
in click run in debugger = works, anything else=has bug (with or without
ICD=true set - this is CCS PIC-C) ICK.
This is both with an ICD-U64 and a MPLAB ICD3 as the debugger tool.
Something about debugging mode is changing the behavior of this code.
So I have two questions:
1) I keep looking at that REAL-ICE debugger, wondering if it is more a real
emulator than the ICD tools we're using.... anyone have experience that
way?
2) Any ideas what would change between running in the debugger and not?
As in, even programming the part with a 'debugger enabled' build still has
the bug, but actually running it using the debugger (no recompile) doesn't?
>
> 2) Any ideas what would change between running in the debugger and not?
> As in, even programming the part with a 'debugger enabled' build still has
> the bug, but actually running it using the debugger (no recompile) doesn't?
>
> -forrest
For PIC24FJ chips (and perhaps others also):
Background Debugger Enable bit (DEBUG) in one of the configuration word is set.
If an ICSP compliant emulator is selected as a debugger, it automatically initializes all of the A/D input pins as digital pins. Maby you have forgotten to change the input pins to digital inputs.
The alternate interrupt vector table (AIVT) may be used instead of the default vectors.
When the In-Circuit Debugger function is used some of the resources are not available for general use. These resources include the first 80 bytes of data RAM and two I/O pins (PGECx and PGEDx).
/Ruben
===========================================
Ruben Jönsson
AB Liros Electronic
Box 9124
200 39 Malmö Sweden http://www.liros.se
Tel +46 40142078
============================================
>
>>
>> 2) Any ideas what would change between running in the debugger and not?
>> As in, even programming the part with a 'debugger enabled' build still has
>> the bug, but actually running it using the debugger (no recompile) doesn't?
>>
>> -forrest
>
>For PIC24FJ chips (and perhaps others also):
>
>Background Debugger Enable bit (DEBUG) in one of the configuration word is set.
>
>If an ICSP compliant emulator is selected as a debugger, it automatically
>initializes all of the A/D input pins as digital pins. Maby you have forgotten
>to change the input pins to digital inputs.
>
>The alternate interrupt vector table (AIVT) may be used instead of the default
>vectors.
>
>When the In-Circuit Debugger function is used some of the resources are not
>available for general use. These resources include the first 80 bytes of data
>RAM and two I/O pins (PGECx and PGEDx).
Also, on some chips the user can select (via configuration registers) which pair
of PGECx/PGEDx pins are used for debugging:
while for programming you can use whatever you wish and the chip will program,
for debugging instead it is absolutely mandatory that the configuration register
bits and the actual PGECx/PGEDx pins match.
I literally wasted 8 minutes of my life once because of this! ;)
This bug turned out to be a situation where under normal 'ICD' operation
(program, then run), for some reason the EEPROM on the part was only being
half-written by the initialization routine. I couldn't figure this out
until I realized I could read the eeprom from the part with the ICD control
program. Once I did that and saw the EEPROM was only half-written (as
opposed to any other possible cause), things got a bit easier to figure out..
After some more frustration, and trying to figure out how in the world a
routine which looks like this:
for (i=0;i<NUMDESCRIPTIONS;i++)
{
for (j=0;j<DESCSTRINGLEN;j++)
{
could ever *not* complete, I realized that perhaps the processor was being
reset by the ICD half way through the initialization. Yep, the ICD-U64,
in a normal "program then run" cycle, bounces the MCLR a couple of times
before it finally releases it - giving my code just enough time to
half-write the eeprom. Then the next run through the code, it uses all of
the strings which got written (including one or more partial one), and does
correct initialization on the rest. Which made a very
hard-to-troubleshoot issue.
Of course, it wasn't doing this when in debugger mode. One good solid
run, instead of the "false start". Which was the frustration which started
this thread.
Unfortunately this code was old enough that it doesn't have the more
refined "write and verify a checksum" code which gets used in most of our
newer stuff. Good news is that's easy enough to add - just move that
code over from another project.
-forrest
On 7/2/2012 5:54 PM, Forrest Christian wrote:
Yet again, I find myself in the unique situation where I actually want to
use the ICD as an actual debugger, and enabling it fixes the problem. As
in click run in debugger = works, anything else=has bug (with or without
ICD=true set - this is CCS PIC-C) ICK.
This is both with an ICD-U64 and a MPLAB ICD3 as the debugger tool.
Something about debugging mode is changing the behavior of this code.
So I have two questions:
1) I keep looking at that REAL-ICE debugger, wondering if it is more a real
emulator than the ICD tools we're using.... anyone have experience that
way?
2) Any ideas what would change between running in the debugger and not?
As in, even programming the part with a 'debugger enabled' build still has
the bug, but actually running it using the debugger (no recompile) doesn't?
>I realized that perhaps the processor was being reset by the ICD
>half way through the initialization. Yep, the ICD-U64, in a normal
>"program then run" cycle, bounces the MCLR a couple of times before
>it finally releases it - giving my code just enough time to
>half-write the eeprom.
Thanks for sharing the above. It might easily save someone else (like me) some immense frustration sometime down the road.
For what its worth, it might be worth mentioning this to the CCS folks - maybe they can come up with a fix.
At 01.21 2012.07.04, you wrote:
>At 04:30 PM 7/3/2012, Forrest Christian wrote:
>
>>I realized that perhaps the processor was being reset by the ICD
>>half way through the initialization. Yep, the ICD-U64, in a normal
>>"program then run" cycle, bounces the MCLR a couple of times before
>>it finally releases it - giving my code just enough time to
>>half-write the eeprom.
>
>Thanks for sharing the above. It might easily save someone else
>(like me) some immense frustration sometime down the road.
This double reset thing of the ICD3 has bothered me too in an occasion.
I don't understand why it does it, but it does it.
planet.eon.net>