View previous topic :: View next topic |
Author |
Message |
jonnewbill
Joined: 29 Jul 2015 Posts: 10
|
Numerous CCS Debugger Issues with PIC18F87J94 |
Posted: Fri Sep 11, 2015 12:22 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Sep 11, 2015 2:27 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Fri Sep 11, 2015 3:42 am |
|
|
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?) |
|
![](templates/subSilver/images/spacer.gif) |
jonnewbill
Joined: 29 Jul 2015 Posts: 10
|
Software Breakpoints and Skidding |
Posted: Fri Sep 11, 2015 11:55 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
Re: Software Breakpoints and Skidding |
Posted: Fri Sep 11, 2015 1:20 pm |
|
|
jonnewbill wrote: | 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? |
Load & run mindset for me. I use a combination of LCD, serial port and CAN messages (depending on the board) and blinking LEDs to debug my code.
Not the optimal approach but it's what I'm used to. |
|
![](templates/subSilver/images/spacer.gif) |
|