Numerous CCS Debugger Issues with PIC18F87J94

[jonnewbill]

I posted a week ago regarding two debugger issues on loss of current execution point and WATCH failure. That post has over 200 views but only one response which did not resolve either issue. I'm wondering if I am the only one having such significant issues with the CCS debugger. Here's a list of the issues I am running into every day in every debug session.

1. Single stepping does step but then loses current location (no green arrow)

2. Single stepping goes into RUN mode. Manually breaking shows execution is way past the point of the single step.

3. WATCH window refuses to display local automatic variables while inside the function where they are in scope. ERR#12 Undefined identifier

4. WATCH window refuses to display function parameters when execution is inside function. ERR#12 Undefined identifier

5. Setting breakpoint in code that I know is executing in the main loop then selecting RUN enters RUN mode and stays there without breaking. Manually breaking shows execution is past breakpoint.

6. Debugger displays erroneous values for constant arrays stored in program memory.

7. Trying to set a breakpoint on the first statement (a function call) within a function instead of setting breakpoint on the selected line sets it on the next executable source line.

I'm using PIC18F87J94 with CCS Compiler V5.048

Any help is appreciated

Jon
_________________
I remember the days before OPS (Other Peoples Software) when all the bytes in my computer were written by me.

[PCM programmer]

I don't have the CCS IDE or ICDU-64 or even that PIC. But if you post
a simple, compilable test program that demonstrates your problems, I
can compile it and test it with a PicKit 3 in MPLAB 8.92 with CCS 5.048.
I can see if I get your same problems.

[RF_Developer]

I don't have time at the moment to discuss any of these points in detail, but I feel its worth thinking about the implications raised by this document:

http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en556761.pdf

In short, some of the problems you raise are related to hardware limitiations, and others are related to code implementation. Others relate to the problems posed by the Harvard architechture, and to optimisation and code generation issues (e.g. one question is: how exactly could breakpoints in inline routines be implemented? Anothers are: how is parameter passing acheived without a data stack, and where would local varaibles be placed? How can a debugger find them?)

[jonnewbill]

RF_Develooper,
Thanks for the link. It was most helpful. My embedded background for past 10+ years has been with TI MSP430's and the IAR C++ compiler. The PIC18 is the first processor I've worked with that has Harvard Architecture. I didn't realize there were any modern processors that used Harvard. On the MSP430 I was familiar with the limitations of hardware breakpoints although the concept of skidding is new to me. The MSP430 also has limited hardware breakpoints but I never experienced any skidding with that processor. On MSP430 a HW breakpoint broke exactly where requested.

I was also already familiar with the concept of software breakpoints since that is what desktop computers use since code is always executing from RAM. What I didn't understand from the article is how software breakpoints are implemented in an embedded system where code is in flash memory. I'm not familiar with the MPLAB IDE referred to in the article since all I've used on the PICC is CCS C. Is the article promoting the use of an In Circuit Emulator (ICE) where flash memory is emulated with RAM so program is stored in RAM? Or is the debugger implementing software breakpoints by reprogramming flash during the debug session? Also the article states that SW breakpoints are only possible in the future with PICC18F parts (which is what I have) It didn't explain what features are required (other than SW breakpoint instruction) on the PICC to implement software breakpoints.

The article also confirmed my suspicion that one of the HW breakpoints is required to do some single step operations such as STEP OVER. I asked this specific question of CCS Tech support last week and was told no single stepping does not require a breakpoint. From the article it is clear that not needing HW breakpoints is only true for STEP INTO and not for STEP OVER. Although the CCS debugger gives no message when STEP OVER is used while all 3 HW breakpoints are assigned. It does seem to go much slower when stepping over a function call so maybe CCS is using the STEP INTO repetitively to implement STEP OVER.

What I conclude from this is the PICC processors are designed more for speed of execution than ease or speed of code development.

Still interested in how veteran PICC developers work around all these issues. Do you pay for an ICE? Use non-debugger techniques like load it and run? Store everything in global variables so WATCH can display it?
_________________
I remember the days before OPS (Other Peoples Software) when all the bytes in my computer were written by me.

[newguy]