| View previous topic :: View next topic |
| Author |
Message |
SeeCwriter
Joined: 18 Nov 2013
Posts: 160
|
| Using Debugger |
 Posted: Mon Jan 07, 2019 1:32 pm |
 |
|
I am using v5.082 with an 18F67K22. When I compile in debug mode, and load my program, I cannot single step through the code. If I just click Run (green arrow) the program runs. If I click Step Over, or Run to Cursor, the status says its Running, but it never goes anywhere. It stays that way forever until I hit the Halt button. Then I get an error message that says "Could not run the target: The target was not halted". After hitting OK on the error message, the status goes back to Ready MCU. And if I hit the Run again, the program never really runs, even though the status changes to Running. I have to exit the debugger and then restart the debugger to reload the program, then it will run if I click the Run button. It never runs when I click single-step or Run to cursor.
This is the test code. Is there some debugger setup I am missing?
| Code: |
#include <18F67K22.h>
#device ICD=TRUE
#fuses NOWDT
#use delay(internal=16MHz)
void main(void)
{
while(TRUE)
{
delay_ms(500);
output_low(PIN_C2);
delay_ms(500);
output_high(PIN_C2);
}
}
|
I should also add that I tried setting a breakpoint at the first delay_ms and it shows up in the Breaks tab of the debugger. But the program never gets there, and in fact does not run. But when I click the Halt button, it no longer gives me the error message. It just changes the status to MCU Ready at 0.14 MHz. And what's up with that frequency. It that correct? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jan 07, 2019 2:16 pm |
|
|
You need to tell us:
1. Are you debugging with a hardware ICD unit or in a simulator ?
2. If ICD, what ICD ? CCS ICD-U40, U64, etc., or MPLAB ICD-3, 4 or
Pickit ?
3. What IDE are you using, and the version ? ie. CCS, MPLAB 8.92 or
MPLAB-X vs. ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Mon Jan 07, 2019 2:49 pm |
|
|
Triple check your connections. Too small a pull-up on the MCLR pin can
make it behave like this, or a cable that is too long (particularly on the more
modern fast USB ICD's the cable really does have to be short).
I've had wrong clock speed reported when the cable is slightly too long. |
|
|
SeeCwriter
Joined: 18 Nov 2013
Posts: 160
|
|
| Posted: Mon Jan 07, 2019 3:21 pm |
|
|
I was using the ICD-U80. I found an old U64 and now the debugging works. I've never run across this problem before. Good to know.
Thanks. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Mon Jan 07, 2019 3:45 pm |
|
|
I've never had good luck with a U80. In my last interaction with CCS last month they said that the newest FW and the latest version of ccsload supposedly made a big difference, but I honestly can't be bothered to test it all. The U64 is my go-to "old reliable."
...And while I'm at it, the Load-n-Go was honestly very good. Never tried debugging with it, but it always worked for me. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Tue Jan 08, 2019 1:26 am |
|
|
Critical data here ICD-U80... 
These are 'interesting'. Seem to work fine for most of the older PIC18's.
Have a lot of issues on PIC24's & 33's.
Looks as if it has issues with this particular PIC18 as well....
They do also seem to be 'fussier' about the cable length than the U40, and
U64.
A lot of issues in general with these.
I spent quite a while batting backwards and forwards with CCS with a
debugging issue with this unit on a couple of PIC24's. What was
interesting was a Mach-X worked fine, but the U80 gave nothing but
problems. They did eventually get me software that worked, so it might
well be worth making sure the unit has been updated to the latest
firmware. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
