ICD-U64 programming issue [SOLVED for now]

[benoitstjean]

Device: PIC24EP512GP806
Compiler: 5.026

I've got a really weird issue going-on and I am quite puzzled at the moment and don't know where to look.

So I've got my ICD-U64 programmer connected to a new PCB revision. It seems to be programming the chip but almost consistently fails on the read to "verify" at the end of the programming cycle. Yes, I know it's a new revision but I was able to program the chip several times today successfully... please keep-on reading.

I tried programming using the standalone CCS programming software (CCSLOAD.exe rather than from within the compiler) and at the end of the programming sequence, it says 'verification failed'. If I click on the "Verify errors" at the bottom, a "Verification results" window opens with some configuration fuses and some of them are in red and quite frankly, in the 4+ years and many revisions of PCBs using the same circuitry, this is the first time I am running into this issue and although it's a new PCB revision, that portion has not changed since the last rev.

Back to the fuses window, it says "Actual: RESET_AUX, Expected: RESET_PRIMARY" (that one, the column is partially cut but that's what it seems it's saying).

Then there's another one with a bunch of fuses like 9L, 10L, 12L etc. Not sure either what these are but there's an L and an H version for each numbers from 1L to 16H. A bunch of them are in red: 8L, 9L, 10L, 12L, 14L, 15L and 16L. They all say "Actual: 0000, Expected: some number that varies from one fuse to another".

How should I interpret these fuses and and what could be the fault?

Question: On the previous PCB version, VCap on pin 56 is a 10uF tantalum cap and the voltage reads 2.58V and on the new rev, it reads 1.8V. Not sure why because it's the same cap. Does this voltage influence anything on the programming end?

Circuit voltage is 3.5V and seems pretty clean on my scope.

Weird thing also is that with CCSLOAD, everything in the Device window shows that all is fine. In the Diagnostics window, on occasions I will click "Read Device ID" and it will succeed but the programming has failed.

Any ideas?

Thanks,

Ben


[EDIT] Using CCSLOAD, I can do a "Read" chip and dump the contents to a file.

The "Verify" option works and simply says "Chip not erased".

The "Checksum" option seems to work also.

Continuity between the contacts inside the ICD-U64's RJ14 to the contacts on my PCB for my connector are all fine.

[PCM programmer]

[benoitstjean]

Hmmm... So the 1.8V I see then on VCap seems fine. And it is in fact a low ESR cap (DigiKey p/n 478-1655-1-ND).

So if this is fine, why am I getting sporadic programming issues....

I'll continue to test tomorrow when I return to work.

Oh and I forgot, I wil re-try but this morning, even my PICKIT3 did not want to recognize the chip. But then, all of a sudden, when back with the ICD-U64, I can program the thing.

Any other input is appreciated.

Thanks again,

Ben

[newguy]

Downgrade (roll back) the ICD-U64 firmware. I'm willing to bet your programmer is an early HW rev unit, as are all of mine. If I update my ICD's FW to the latest version, I start getting the same issue as you (and others, depending on the HW rev of the unit).

Long story short, CCS' ICD FW releases are not always backward compatible with earlier HW revisions of the ICD.

[PCM programmer]

[benoitstjean]

Thanks to both of you.

Newguy: I've had my programmer for about 5 years if not more and this is the first time I have such persistent issues. I have not upgraded the FW on the programmer.... it's the original from when it was purchased.

PCM Programmer: For whatever reason, I guess I misread Microchip's specs and didn't realize it was written 1 Ohm. On the other hand, this is the same cap I've been using over and over for more than 4 years on the same circuit (different revisions).

I will try to find a different cap and spend the day today trying to figure-out what is going-on.

I have the PICKIT 3 also so I will give that a try.

Thanks a million,

Ben

[EDIT] I looked on the DigiKey website and found this guy: 478-3451-1-ND... Its ESR value is 200 mOhms so I guess that would work.

[benoitstjean]

I have a few questions regarding the CCS Device Programmer software in the Diagnostics window...

BTW, I changed the 10uF tantalum cap (ESR of 3 ohms) to a 22uF tantalum capacitor DigiKey p/n 399-10275-1-ND I had kicking around and it has an ESR of 500 mOhms and that didn't solve the problem. Different footprint but it's just for testing.

1) The bottom section "Test oscillator and debugger", I enter my external crystal 29,491,200 and select 'Ext Crystal'. Then I click the green button and I am prompted to select which ICD pins I use so I take the first one (PCG1 and PGD1) because I am using pins 17 and 18. Then I run the test and it comes back with "FAIL: Unable to load a test program into the target chip" then says "Details: Verify error". That doesn't explain much as to the typical problems that can spew-out this error.

2) The "Read Device ID" and "Start Continuous read of IDs" works fine.

3) The target VDD indicator is at 3.5V.

4) I noticed inside the ICD-U64 that there's a 3-pin header but there's no jumper on it. It has always been like this though... so I'm not sure if this can be an issue or not.

5) All 4 GND pins on the MCU (9, 20, 25 and 41) are properly tied to GND

6) If I test each pin using the CLR / PGD and PGC buttons in the middle pane, these are the results:

a) MCLR (pin 7): VSS: 0.098, VDD: 3.51, VPP: 3.51
b) PGD (pin 18): VSS: 0.132, VDD: 3.51, INPUT: 3.51
c) PGC (pin 17): VSS: 0.0017, VDD: 3.51
d) B3 (pin 13): VSS: 0.0143, VDD: 3.51, INPUT: 0.0143

After testing B3 as "input" and seeing it drop to 0.0143, I'm now wondering why is pin PGD as "input" not dropping? Is this normal?

I find it also strange that the VSS for MCLR and PGD don't drop as low as PGC but I don't know what it's doing inside the MCU so that might be normal.

One weird thing: although the "verification" always fails, it still seems that the program is properly loaded. I took a completely different program and programmed it and although I keep getting verification failures, the program runs.

I will continue to post my findings but any input is appreciated.

Thanks again,

Ben

[newguy]

I'm using ccsload.exe, rev 5.034. My ICD-U64 is HW rev 2, and I'm running FW rev 2.96. I'm currently developing FW for a board with a dsPIC33FJ256GP710A.

If I update my ICD to any FW rev 3.xxx, I get symptoms precisely like you describe: the processor is detected properly and seems to program properly, but I get verification errors.

For the heck of it, please try changing your ICD FW to something other than what you're presently running.

And the internal 3 pin header, I believe, is for the ICD to supply Vcc to the circuit or not. Default is for it NOT to power the circuit.

[benoitstjean]

There are a few reasons I am reluctant in upgrading the FW on the programmer:

1) How do I get back the previous FW if the new one fails?

2) This programmer along with the PIC24EP512GP806 has been working with other boards for quite some time but this new one (new as in a new revision of the board - same schematics, different layout) is causing me grief;

3) I can program the PIC because I see the new code run.... but it fails consistently with the verification step at the end;


Good thing for now is that I was able to program a bootloader into the PIC and although the verification fails, it appears that the code works because I loaded my real program through my serial cable tied to the MCU's serial port so maybe if this works for now, it's a workaround (but I still need to know why the heck it is failing all of a sudden);

The things I still cannot figure-out for now is why is the clock test using CCS's program fails, the pin test seem fine except for the input test on PGD as shown in my previous post...?

I have just tried a new test and I am starting to point the ICD programmer... The reason I am pointing the programmer is that I just tried re-programming older units that have been working for years and I am now getting the same issue. One of them I programmed just last week and it worked.... so could it be the programmer? I'm starting to think that that's what it is...

Ben

[newguy]

The programmer FW is usually stored in the same directory as ccsload.exe. There are several versions there. When you go to the update FW button/tab, there is a drop down box with the various versions available on your system.

I understand why you're reluctant to try it and it does indeed sound like perhaps your ICD is failing. ...But sometimes just re-flashing the FW into a misbehaving device (not just a programmer) can get it to start behaving again.

[benoitstjean]

Yeah I just tried that and it behaves the same.

As for the pin test using the CCS software, I did not properly test the inputs.... now I realized the mistake I did and the inputs B3 and PGD work. When I click the "input" button and tie the pin to GND, the VSS button lights-up. Same with tying the pin to 3.5V, VDD lights-up. So connectivity-wise, all is fine.

Ben


[EDIT] Connectivity is all fine, I can control all pin signals through CCS's software. The only test that fails is the oscillator test. But then again, overall, programming fails at the end.

[benoitstjean]

So it appears **maybe** that all this could be caused by a bad CCS database / database mismatch. I have no idea how this could have happened but anyways, I have had some success after opening a ticket with CCS.

I will post more tomorrow when I get to work. But in the meantime, in the <C:\Program Files(X86)\PICC> folder, there's a file called <devices5p.dat> (note the letter 'p' in the name). There's also a file called <devices5.dat> (without a 'p' in the name) in the <PICC\DLL\5.026> folder.

These files are used by the compiler and CCSload program and I think they must be the same.

I have a ticket opened with CCS. The idea here is to rename the <\PICC\DLL\5.026\devices5.dat> to something else like .backup and take the one in the root PICC folder and copy it in the <PICC\DLL\5.026> folder and remove the 'p' from the name to replace the original.

When I did this, programming started to work magically without touching the hardware.

I still cannot explain why CCS Load fails the oscillator test.

And there are still a few things that I need to check and confirm with CCS but once all is done, I will post CCS's emails here.

So stand-by...

Ben

[benoitstjean]

So I guess that after a few days of tests and email exchange wih CCS support, it really points to a corrupted database or something.

It is very hard to pinpoint the exact issue but trying a different combination of CCS load and ICD-U64 firmwares, different problems showed-up.

I installed compiler 5.069 and now all is fine.... like it never happened.

If I find anything new, I will post here.

One of the weird things I was noticing is that a perfectly good program would compile and burn but the MCU did not work as expected. Although the code indicated that my oscillator was 29491200 Hz and the UART was set at 115200, the HEX file had a UART configuration of 11527 (about 10 times less) and CCS reported that the fuses were all wrong. But prior to last week, this program worked perfectly. Given I knew this program was good, that's when I attempted to try that one and the UART issue showed-up.... but the same UART and clock configuration was used in another program and that program ran just fine but the burning reported "verification error" at the end.

I hope this helps.

I have marked the post as solved.

Thanks guys for all your help. Good job also to CCS support for their quick and effective responses.

Ben

[benoitstjean]

After a week trying different combinations of CCS load, ICD-U64 firmware and compiler versions, I was able to get my hands on the original 5.026.

Before going to that version, I also compiler 5.056 and 5.069, both with 2.95 and 3.21 firmware in the ICD. Although the code compiled fine, towards the end of the circuit's initialization routine, the MCU froze.

Prior to re-installing a fresh copy of 5.026, I ran the 'faulty' 5.026 (the version that had consistent verification errors at the end of the programming cycle) and a fresh copy of 5.069 both with the ICD running FW 3.21 in both cases.

I loaded PCW 5.026, took my project, hit CLEAN, REBUILD ALL and PROGRAM... program worked as expected other than "verification error" at the end of the programming cycle.

I closed 5.026 and loaded 5.069 and did the same thing: CLEAN, REBUiLD ALL and PROGRAM. This time, programming was fine but MCU froze at the end of the circuit's initialization cycle.

By initialization cycle, I mean that the MCU initializes a bunch of external components like a modem, an SD card, an accelerometer etc.

So same program, same ICD FW, different compiler version, different results.

I have then uninstalled and deleted the folders of the CCS stuff I had and proceeded with a fresh install of 5.026 and downgraded the ICD back to 2.95. Now all seems to be working just fine like it has been for the last 3+ years.

If I find anything else, I will post here.

Benoit