CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

CCS command for setting programming/debugging pins on PIC24
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
reelthymes



Joined: 26 Jul 2024
Posts: 21

View user's profile Send private message

CCS command for setting programming/debugging pins on PIC24
PostPosted: Tue Nov 26, 2024 7:27 am     Reply with quote

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: 1934
Location: Norman, OK

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 8:46 am     Reply with quote

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: 1354

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 9:54 am     Reply with quote

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: 19539

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 10:04 am     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 10:55 am     Reply with quote

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:

Quote:
#fuses ICSP2


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:

Quote:
#DEVICE ICD=2


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

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 11:11 am     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 12:03 pm     Reply with quote

UPDATE:


I moved the line

Code:
#device ICD=2


higher up in the code, and this has solved the compiler error I was seeing before.
jeremiah



Joined: 20 Jul 2010
Posts: 1354

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 12:37 pm     Reply with quote

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: 19539

View user's profile Send private message

PostPosted: Tue Nov 26, 2024 12:40 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Nov 27, 2024 9:54 am     Reply with quote

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: 1354

View user's profile Send private message

PostPosted: Wed Nov 27, 2024 10:20 am     Reply with quote

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: 19539

View user's profile Send private message

PostPosted: Wed Nov 27, 2024 11:38 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 02, 2024 11:57 am     Reply with quote

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: 19539

View user's profile Send private message

PostPosted: Mon Dec 02, 2024 1:02 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 02, 2024 1:31 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group