Fuse settings for using CCS ICD debugger

[Richard Carter]

There is a land mine in the CCS tool kit that I stepped on. I build two versions of my software, one for debug and one for release. The tool kit ignores preprocessor directives when parsing fuses and device directives. The statements below generate release fuse settings even if DEBUG_FUSES is defined.

#ifdef DEBUG_FUSES /* debug fuse settings */
#device pic16f876 *=16 CCSICD=TRUE #fuses HS,NOWDT,NOPROTECT,NOBROWNOUT,NOLVP
#else /* release fuse settings */
#device pic16f876 *=16
#fuses HS,WDT,NOPROTECT,BROWNOUT,NOLVP
#endif

The two fuse settings above appear to work, you just can't define them both and expect the preprocessor to chose one. I now hand edit my source file when changing from debug to release versions.

I spent a couple of long nights on this. CCS is not known for providing detailed help, so I figured I save some other sucker a few long nights by posting something here. Hope this helps.
_________________
Richard Carter
KE1EV@ARRL.net

[PCM programmer]

I did a test, and I didn't have a problem. To get it to compile,
I had to move the #fuses statement onto its own line.
But once I did that, if I commented out the #define statement
at the top, and looked at the .HEX file, there were definitely
different config bits for for each compilation. So the #ifdef-#else
statements are working properly (in PCM vs. 3.183).

#define DEBUG_FUSES 1

#ifdef DEBUG_FUSES /* debug fuse settings */
#device pic16f876 *=16 CCSICD=TRUE
#fuses HS,NOWDT,NOPROTECT,NOBROWNOUT,NOLVP
#else /* release fuse settings */
#device pic16f876 *=16
#fuses HS,WDT,NOPROTECT,BROWNOUT,NOLVP
#endif

I did find that this line causes a problem:
CCSICD=TRUE

Is that a valid pre-processor command ? I thought it was:
ICD=TRUE

In fact, if I compile it as you had it, the Fosc bits in the Config word
always end as 11, which is the RC oscillator.

So I did a further experiment. I tried it with a "garbage" prefix:
#device pic16f876 *=16 XYZICD=TRUE

Result: It compiles with no error. But it sets the Fosc bits in the
config word for the RC oscillator.
---------------------------------------

Further testing:

If I make a simple program, such as this, no Config word statement
is generated in the HEX file:

#device PIC16F877 ICD=TRUE

main()
{

while(1);
}

If, however, I put some garbage characters in front of "ICD",
as shown below, then it generates this line in the HEX file.
This line contains Config bits (ie, "fuses"), when none were specified.
:02400E00333746

#device PIC16F877 XYZICD=TRUE

main()
{

while(1);
}

Conclusions:

1. I think part of the problem may be due to your using CCSICD,
when you should be using ICD.

2. The rest of the problem may be, that you need to specifically
re-load the .HEX file into your editor after doing a compilation.
I found that I had to close the old hex file window, and load
the new HEX file from disk, in order to see the latest version.
Just re-loading the file while an existing one was open, was
not good enough. MPLAB wouldn't display the new HEX file.

I don't know what programmer you're using, but the HEX file
may not be updated or saved properly in whatever directory your
programmer is using. I know there was a problem like this
a few years ago on this board.
---------------------------------------------------------------------

Edited to add:

I discovered an explanation for part of this. If you include
ICD=TRUE, then CCS forces the DEBUG bit in the fuses to
be set. Doing this, will force the .HEX file to contain the
config bit line. But, other important config bits, such as Fosc,
will not be initialized unless you also include a #fuses line
in your program.

Another issue was why did the compiler put the config bits
in the HEX file if garbage characters were put in front
of the ICD=TRUE statement ? I believe the answer is that
the parsing mechanism of the compiler doesn't look for
a space in front of "ICD" when it parses that line. It just
looks for the existence of "ICD=TRUE" on the line. Then
it sets the DEBUG bit in the config bits, as shown above.

[Richard Carter]

I'm using PCB/PCM/PCH V3.158 IDE V3.31. Hopefully, CCS fixed this bug in later releases. From the previous posting, it appears that another bug may have been introduced. If xxxICD is a bad declaration, the tool set should report an error, not stick bad fuse settings in the hex file.

The CCSICD device setting is referenced somewhere in the CCS documentation, but I can't find it at the moment. I called customer support last week and asked about the correct setting. The answer I got was that CCSICD=TRUE gets you a different target agent than ICD=TRUE. The former supports stack trace, whereas the latter doesn't. I'm not comfortable with this explanation since I don't seem to get a stack trace in either case. I can live without stack trace. I can't work with bad fuse settings. If someone can clarify the target agent fuse settings, I'd be grateful. In any case, I get the same bad results with ICD=TRUE.

I'm certain that the code fragment provided in my earlier posting parses correctly and results in bad fuse settings. I verified this by using the CCS IDE to load my target, then switch to a serial ICD running MPLAB to examine the target fuse settings that got loaded. I'm certain that my preprocessor directive was defined correctly because I put a #error statement in the else case. If I simply remove the #else case and associated declarations, I get proper fuse settings.

BTW: In case anyone is interested, I loaded CCS icd firmware into my ICD-1 and it works with the CCS debugger. I used MPLAB to load the firmware into a spare 16F876. I had to remove blank lines from the hex file; quite a tedious task. I then swapped the PIC out and ran the CCS debugger. I can't subsequently upgrade the ICD. I get an error when I attempt to update the firmware. Hey it works, so I won't complain.


Thanks for your time.
_________________
Richard Carter
KE1EV@ARRL.net