View previous topic :: View next topic |
Author |
Message |
charliumi
Joined: 03 Nov 2016 Posts: 11
|
PIC24FJ256GB406 - ICD-U64 programming error |
Posted: Thu Nov 03, 2016 4:31 pm |
|
|
Hi Folks,
I'm trying to use CCS version 5.061 along with ICD-U64 to compile very simple software on PIC24FJ256BG406 and I cannot make it work. The software is actually pretty simple, just a dummy loop that compiles fine. I pick the correct chipset from the Project 24-bit Wizard, without any specific options.
When trying to program the PIC, I'm writing the image but the PIC failed to verify the image and ends with an error message.
Is there anything big I'm missing here ? Any guidance would be much appreciated.
I'm not new to CCS and ICD-U64 as I build several solutions based on PIC16 and PIC18 but it is the first time I'm working with PIC24. So looks like there's something basic I'm not doing properly. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19518
|
|
Posted: Fri Nov 04, 2016 2:52 am |
|
|
Try it directly with CCSLoad. You'll then hopefully get a more informative error message, or it'll work.
I've actually had problems sometimes with the ICD's refusing to program some chips from inside the compiler (though they program them for debug!...). The error message from CCSLoad (and run the diagnostics), may help to say what the problem is. |
|
|
charliumi
Joined: 03 Nov 2016 Posts: 11
|
|
Posted: Fri Nov 04, 2016 7:13 am |
|
|
Thanks for the suggestion. Actually, I already tried this before and wasn't able to find significant issue under diagnostic. The PIC is well recognized, I can read the Target Device ID and all PIN looks ok when testing with tension on it. The only thing I notice is upon selection of 'Verify Errors', the program memory columns is filled with FF (Actual) and Expected is completely different - this is the case for all lines (each address). On the left window, I have the following message '3251 errors from 0 to 8007F3', which correspond to the discrepancies between the actual column and the Expected column.
What also looks new to me is the programming is happening in 2 stages : Programming Executive then Programming the actual file.hex from my software. Looks like the issue is happening on the verification of the file.hex.
I assume this 2 stages is related to the DualFlash capabilities so I'm wondering if something needs to be done in CCS to accommodate this.
Thanks for your help, |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19518
|
|
Posted: Fri Nov 04, 2016 12:53 pm |
|
|
The "Programming executive" title is used for the code for enhanced ICSP. Not dual Flash. This is used to allow much faster programming than the standard mode. It's sounding as if it is this that is actually failing to work. This could happen if the cable is a little long (the enhanced mode requires much tighter timings), or there is an unexpected load on the ICSP pins. |
|
|
MikeP
Joined: 07 Sep 2003 Posts: 49
|
|
Posted: Fri Nov 04, 2016 3:18 pm |
|
|
I have support request in with CCS right now with the same issues with most of the PIC24 chips I am trying to use. All are failing to verify.
PIC24EP64GB202
PIC24EP512GU810
PIC24FJ128GA010
I am using version 5.025.
CCS support asked me to change/check some setting inside the IDE. Still does not work. Currently waiting the them to review the debug log they asked for from CCSLoad for like a week and a half now.
Maybe the problems are related, poke them about your problem maybe they fix this |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19518
|
|
Posted: Sat Nov 05, 2016 2:37 am |
|
|
It's possible that the programming executive being used has problems. This then stops the enhanced mode from working. Microchip has had this, with several different revisions being needed to get some chips working... :( |
|
|
MikeP
Joined: 07 Sep 2003 Posts: 49
|
|
Posted: Fri Nov 11, 2016 6:09 pm |
|
|
Is your problem fixed? |
|
|
charliumi
Joined: 03 Nov 2016 Posts: 11
|
|
Posted: Thu Dec 08, 2016 3:25 pm |
|
|
so, what is the conclusion here ? How to we get this to work with PIC24 ?
Anybody from CCS could shim in ? |
|
|
charliumi
Joined: 03 Nov 2016 Posts: 11
|
|
Posted: Thu Dec 08, 2016 3:30 pm |
|
|
I just tried with a newer release 5.034 and Firmware 3.18 and there's no improvement. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1908
|
|
Posted: Thu Dec 08, 2016 3:57 pm |
|
|
Try downgrading the FW for your programmer. I had a similar issue with an old ICD-U64 and a dsPIC33FJ256GP710A. Once I downgraded the ICD, it started to program and verify properly with no errors. |
|
|
gaugeguy
Joined: 05 Apr 2011 Posts: 303
|
|
Posted: Thu Dec 08, 2016 4:14 pm |
|
|
I am able to program a PIC24FJ256GA406 using the ICD-U64. Software: 5.034, Firmware 3.18, Hardware: Rev 3.
The target board is self powered at 3.3V and I used ccsload.
I normally use ICD3 with MPLABX IPE because it programs faster but I hooked the ICD-U64 up to test it out again. |
|
|
charliumi
Joined: 03 Nov 2016 Posts: 11
|
Solution |
Posted: Fri Dec 09, 2016 8:12 pm |
|
|
Hi Gang,
I finally make it work. The problem was related to default FUSES Configuration. By the default, the option 'WDT clock source is determined by WDTCLK configuration Fuses' is selected when you use the Wizard24bits. Once unselected, you can program the chip. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19518
|
|
Posted: Sat Dec 10, 2016 3:25 am |
|
|
You can now see why the 'regular users' hate the Wizards..... |
|
|
charliumi
Joined: 03 Nov 2016 Posts: 11
|
Correction -false positive |
Posted: Sat Dec 10, 2016 3:17 pm |
|
|
I reported a false positive .. actually I've been able to program the PIC twice but some reason I'm still trying to determine it doesn't work anymore. I will try tomorrow with a new hardware in order to eliminate issues with the board where the PIC24F is - even if I don't believe it. When I run the diagnostic tool, I can read the Device ID of the PIC and all verification looks corrects.
I think the issue is really with CSS configuration. Now it doesn't work anymore, I found that even if the FUSES NOWDTCLK is in the configuration,
when you open the file .hex in the configuration section, the option "WDT clock source is determined by the WDTCLK configuration' is still Selected.
When looking at the verification error log, in the fuse section, there's a error message 'Actual = WDTCLK_LPRC, Expected =RESERVED'
Anybody has clue about what it means ? |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19518
|
|
Posted: Sat Dec 10, 2016 3:25 pm |
|
|
One thing that always affects the watchdog setting, is if you have DEBUG enabled. |
|
|
|