CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

icd hits breakpoint even when I don't set one

 
Post new topic   Reply to topic    CCS Forum Index -> CCS ICD / Mach X / Load-n-Go
View previous topic :: View next topic  
Author Message
[email protected]



Joined: 03 Jan 2005
Posts: 9
Location: upstate NY

View user's profile Send private message

icd hits breakpoint even when I don't set one
PostPosted: Sat Apr 02, 2005 5:36 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sat Apr 02, 2005 12:20 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> CCS ICD / Mach X / Load-n-Go All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group