mhahn@hvc.rr.com
Joined: 03 Jan 2005
Posts: 9
Location: upstate NY
|
| icd hits breakpoint even when I don't set one |
 Posted: Sat Apr 02, 2005 5:36 am |
 |
|
I'm seeing very strange behavior using an ICD-U with an 18f8720. If I have code at address 0xFCC2, and never set a breakpoint, the debugger will behave as if it hit a breakpoint when the code at 0xFCC2 executes. Once the debugger hits this "phantom" breakpoint it never seems to work right again. It reports variables as having wierd values, single steps thru if statements in ways that should not happen, etc.
I've seen this on 2 different 18f8720 processors. Has anybody else seen this on other processors with lots of ROM?
By the way, if you are running into this, you can org a routine you never actually run to overlay the 0xFCC2 address.
Regards,
Mark
Here's a very short program that reproduces the problem:
| Code: |
// include 18f8720 definitions
#include <18f8720.h>
//
// compiler specific directives
//
// compiler specific directive for use with ICD
// remove in production code
#DEVICE ICD=TRUE
// have AtoD routines return 10 bit values
#DEVICE ADC=10
// 14.74Mhz clock on CAYENNE
#use DELAY(CLOCK=14740000)
// configuration fuse settings
#fuses HS,NOOSCSEN,BROWNOUT,WDT128,NOWDT,BORV25,PUT,NOWAIT,MCU,CCP2C1,STVREN,DEBUG,NOLVP,NOPROTECT,NOCPD,NOCPB,NOWRT,NOWRTD,NOWRTC,NOWRTB,NOEBTR,NOEBTRB
// using fast_io saves a bit of rom and time
// just be sure to explicitly set IO pin direction
#use FAST_IO(A)
#use FAST_IO(B)
#use FAST_IO(C)
#use FAST_IO(D)
#use FAST_IO(E)
#use FAST_IO(F)
#use FAST_IO(G)
#use FAST_IO(H)
#org 0xFCB0,0xFCFF
void die(void)
{
#asm
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop // 0xFCC2 ... this is where the debugger shows the break happening
nop
nop
nop
nop
#endasm
}
//
// main:
// Everybody's favorite C function.
//
void main (void)
{
long int ii;
die();
for (ii=0; ii<1000; ii++)
{
}
}
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Apr 02, 2005 12:20 pm |
|
|
I don't have the CCS ICD, so I can't know for certain that this is the
problem, but with the Microchip ICD2 the debugger reserves some
of the program memory near the end of the address range.
If you look in the Help file for MPLAB 7.01, buried inside there, they
have the debugger limitations for the PIC18F8720 devices. The ICD2
uses program memory range 0x1FDC0 - 0x1FFFF. It's used to hold
the "debug executive" program. You can't use it.
I suspect that you're seeing something similar with the CCS ICD.
It may "break" on it's own debug executive. |
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
