| View previous topic :: View next topic |
| Author |
Message |
reelthymes
Joined: 26 Jul 2024
Posts: 21
|
| CCS command for setting programming/debugging pins on PIC24 |
 Posted: Tue Nov 26, 2024 7:27 am |
 |
|
Hi,
I have inherited a design and code for a PIC24-based device. I am using MPLAB v8.92 with the PCD CCS compiler. Recently I have tried to debug the PIC24 using a PicKit3 programmer/debugger but the MPLAB IDE comes back with this error:
| Quote: | PK3Err0040: The target device is not ready for debugging.
Please check your configuration bit settings and program
the device before proceeding. |
On the Microchip forum, someone pointed out the following:
| Quote: | That PIC device does have three sets of programming pins (PGED1/PGEC1, PGED2/PGEC2, PGED3/PGEC3) You can program via any of the three pairs, but you can only debug via the set selected in your CONFIG settings via the ICS# bits in "CW1: FLASH CONFIGURATION WORD 1" This must be set to match which pair of pins you actually have the PK3 connected to. Sorry, I do not know the syntax for that in CCS C, I only use the Microchip supplied XC compilers.
|
So I am trying to confirm in my code where those programming pins are set and I can't find a reference to them. I figure that if I can find where the programming pins are set, and can also set the debugging function to use that same pin set. I looked through the PCD compiler manual for a command relating to setting the pins for the PGEDx and PGECx, but haven't found a reference to it, though I might be missing it.
Can anyone speak to this?
Thank you |
|
 |
dyeatman
Joined: 06 Sep 2003
Posts: 1938
Location: Norman, OK
|
|
| Posted: Tue Nov 26, 2024 8:46 am |
|
|
Page 133 of the November 2021 manual shows the ICD pin selection settings
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1358
|
|
| Posted: Tue Nov 26, 2024 9:54 am |
|
|
Just a note that you can program on any of the interfaces without needing to set anything (they are all internally connected for programming). You do need to set it up for debugging (and also if using the ICD-U80/U64 for a serial port).
usually can specify which set with #device:
debugging:
| Code: |
#device ICD=2 // use 2nd set
|
ICD-U64/U80 as serial port:
| Code: |
#device ICSP=2 // use 2nd set
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19559
|
|
| Posted: Tue Nov 26, 2024 10:04 am |
|
|
But also 'not ready' suggests the code has been compiled without ICD=TRUE.
Just search in the manual, for ICD. Second entry: #device. |
|
|
reelthymes
Joined: 26 Jul 2024
Posts: 21
|
|
| Posted: Tue Nov 26, 2024 10:55 am |
|
|
Thanks, I checked the manual and I see the following:
| Quote: | ICD=TRUE
Generates code compatible with Microchips ICD debugging
hardware.
ICD=n
For chips with multiple ICSP ports specify the port number
being used. The default is 1. |
In my code, the following line is here:
so if I understand correctly, that means my design is using the second set of pins, which would make sense because the programming interface is indeed connected to pins 17 & 18.
So in order to enable debugging on those pins too, I included the below line after the above line that set ICSP2:
I get the following compile errors for that particular line:
| Quote: | 1. Can not set this option this far into the code ICD=TRUE
2. Extra characters on preprocessor command line |
Does anyone know why? |
|
|
reelthymes
Joined: 26 Jul 2024
Posts: 21
|
|
| Posted: Tue Nov 26, 2024 11:11 am |
|
|
| jeremiah wrote: | | Just a note that you can program on any of the interfaces without needing to set anything (they are all internally connected for programming). |
In light of that fact, what do you think the below line is doing?
#fuses ICSP2
I thought it was setting the second set of pins as the programming pins, but if that's not needed, is this redundant? |
|
|
reelthymes
Joined: 26 Jul 2024
Posts: 21
|
|
| Posted: Tue Nov 26, 2024 12:03 pm |
|
|
UPDATE:
I moved the line
higher up in the code, and this has solved the compiler error I was seeing before. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1358
|
|
| Posted: Tue Nov 26, 2024 12:37 pm |
|
|
| reelthymes wrote: | | jeremiah wrote: | | Just a note that you can program on any of the interfaces without needing to set anything (they are all internally connected for programming). |
In light of that fact, what do you think the below line is doing?
#fuses ICSP2
I thought it was setting the second set of pins as the programming pins, but if that's not needed, is this redundant? |
Just as a followup, consider the order of operations. In order to know that fuse, the PIC has to be programmed with it, but to be programmed with it, the PIC already has to know to use that interface. It would be a chicken and the egg problem.
I'd have to look at the data sheet to see exactly what that fuse does, but I would guess it has to do with special debugging features. I now the "#device ICSP=2" directive sets up anscillary operations for the CCS chip programmer (data streaming, serial port over programmer, automatic data graphing, etc.), but I don't know if it relates to the fuse of the same name or not.
Last edited by jeremiah on Tue Nov 26, 2024 10:38 pm; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19559
|
|
| Posted: Tue Nov 26, 2024 12:40 pm |
|
|
Yes, redundant. In fact the ICSP pins never need setting. Any pair of the
pins can be used for programming. It is the voltages presented that selects
the pins.
Settings like ICD must always be before any code. |
|
|
reelthymes
Joined: 26 Jul 2024
Posts: 21
|
|
| Posted: Wed Nov 27, 2024 9:54 am |
|
|
I am still getting the error from MPLAB that my device is not ready for debugging. Someone on the Microchip forum asked the following question:
| Quote: | | Which oscillator option have you selected in the CONFIG settings? The debugger cannot run if the PIC itself is not running. |
I believe that the #fuses directives are what set the config bits in CCS compiler land. Below are the #fuses statements in my code:
| Code: | | #fuses SOSC_DIG,HS,PR_PLL,NOWDT,PLL5,PROTECT,NODEBUG,ICSP2 |
Do any of those settings look like they would be a problem for debugging? 'NODEBUG' stands out to me, but the only reference to that I found in the manual looks like it has to do with error logging. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1358
|
|
| Posted: Wed Nov 27, 2024 10:20 am |
|
|
Also look at your #use delay() as it has the capability of changing your clock fuses depending on where you place it and what options you select (and they don't reference fuses so you may not know it is happening). The same thing if you are using the setup_oscillator() in your code at all, it will sometimes change fuses in the compiler if the options you select are not compatible with the fuses you picked.
My recommendation, start with a really really simple program with just:
1. you pic include file
2. any necessary #device
3. your fuses
4. your clock statement
5. a very very simple main like:
| Code: |
void main(){
while(TRUE){
}
}
|
Then maybe someone else here has that pic and can try it on their setup and see if debugging works and then report back. You can also try it to see if that changes anything. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19559
|
|
| Posted: Wed Nov 27, 2024 11:38 am |
|
|
You'll also get that if the chip isn't powered. If the board draws more than
the debugger can supply, it's supply needs to be on.
I had that. Was cursing why a bit of code would not run, and had forgotten
I had switched the supply off when moving a cable....
and of course if you have too small a resistor pulling up MCLR. needs to
be quite large (22K).
Depends on which debugger you have. Some of the early ones are very
fussy on this. |
|
|
reelthymes
Joined: 26 Jul 2024
Posts: 21
|
|
| Posted: Mon Dec 02, 2024 11:57 am |
|
|
| jeremiah wrote: | Also look at your #use delay() as it has the capability of changing your clock fuses depending on where you place it and what options you select (and they don't reference fuses so you may not know it is happening). The same thing if you are using the setup_oscillator() in your code at all, it will sometimes change fuses in the compiler if the options you select are not compatible with the fuses you picked.
My recommendation, start with a really really simple program with just:
1. you pic include file
2. any necessary #device
3. your fuses
4. your clock statement
5. a very very simple main like:
| Code: |
void main(){
while(TRUE){
}
}
|
Then maybe someone else here has that pic and can try it on their setup and see if debugging works and then report back. You can also try it to see if that changes anything. |
So I created a new project with the very simple code that you suggested, and I am getting the same error from MPLAB. Below is the simple code:
| Code: | //This is a simple test program to see if I can debug the device with MPLAB
#define __USB_PIC_PERIF__ 1
#include <24FJ256GB206.h>
#device icd=2
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
#fuses SOSC_DIG,HS,PR_PLL,NOWDT,PLL5,PROTECT,NODEBUG,ICSP2
#use delay(clock=32M)
void main()
{
while(TRUE)
{
}
} |
When I compile, I get no errors, but I always get the following warning:
| Quote: |
Warning 227 "foo.c" Line 11(7,12): Feature not supported Instead, Use #device icd=2
|
I wonder if that is indicating something important. That line # is the #fuses line. Why is it telling me that the feature is not supported? If I delete the first #fuses option I listed, it still gives that error. Also, I do have #device icd=2, already in the code above.
One more thing to note, is that whenever I start the debug process and try to step through the code, MPLAB launches a pop-up with the title "target out of date" and the message "MPLAB's memory has changed since the last program, operation, would you like to continue"
That leads me to think that I need to first program the device with this program before debugging. But when I switch to the programmer menu and program it (without errors) and return to try to debug, the same issues happen. It tells me that the target is out of date, and then I get that error that the target is not ready for debugging. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19559
|
|
| Posted: Mon Dec 02, 2024 1:02 pm |
|
|
Use:
| Code: |
#define __USB_PIC_PERIF__ 1
#include <24FJ256GB206.h>
//#device icd=2 //Use if you want to debug
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
#fuses SOSC_DIG
#use delay(clock=32M, crystal=20M)
|
It is complaining, since you both turning on debug and turning it off.
There is _no ICSP setting_ on the chip. Read the programming data sheet
you can always program through any pair of the ICSP pins. There is no
setting to control this. The ICD though needs to be told what pins to use
if you use debug. This only needs setting for debug, _not_ programming.
Only some of the old PIC18's had fuses to select ICSP. This chip does
(and all the rest of the family), do not. |
|
|
reelthymes
Joined: 26 Jul 2024
Posts: 21
|
|
| Posted: Mon Dec 02, 2024 1:31 pm |
|
|
| Ttelmah wrote: | Use:
| Code: |
#define __USB_PIC_PERIF__ 1
#include <24FJ256GB206.h>
//#device icd=2 //Use if you want to debug
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
#fuses SOSC_DIG
#use delay(clock=32M, crystal=20M)
|
It is complaining, since you both turning on debug and turning it off.
There is _no ICSP setting_ on the chip. Read the programming data sheet
you can always program through any pair of the ICSP pins. There is no
setting to control this. The ICD though needs to be told what pins to use
if you use debug. This only needs setting for debug, _not_ programming.
Only some of the old PIC18's had fuses to select ICSP. This chip does
(and all the rest of the family), do not. |
I removed the ICSP_2 and the warning went away. But after trying to debug using the above code, I get the same error. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
