SOLVED: Configuration Fuses Causing Failure When Debugging

mgiuliani · Joined: 30 Mar 2023 Posts: 20

Hi,

I have an ICD-U80 that I'm attempting to use with a PIC24FJ256GA606 chip. I fixed an issue with the firmware verification failing by updating CCSLoader and the firmware on the ICD. After that I now get a Verification Results window popup that shows Configuration Fuses, with a bunch of high and low byte sets with no context as to what those mean along with a list of fuses to the right.

Has anyone seen this before or know what causes this to happen?

Link to a screenshot of what I see below

https://ibb.co/2dV9kVq

Solution:
In CCS Compiler I had to go to Device Editor under the Tools tab, then in the little window it opens there's a scrollable box in the top right for all the config bits. At the bottom of the list there are 12 RESERVED slots. I had to change the top 2 bytes, which by default for me were always 00, to FF for both the VALUE and MASK column. For example the first reserved slot was 007010 and I had to change it to FF7010. Doing that for all 12 RESERVED slots stopped that issue.

After that I had an issue with firmware verification failing after programming. My ICD-U80 was using firmware 3.57. I had to downgrade the firmware using CCSLoader to version 3.22. After changing the 2 bytes in device editor and downgrading the ICD-U80 firmware, debugging is now working successfully with my device.

Thank for the troubleshooting help everyone!

temtronic · Posted: Thu Mar 30, 2023 12:16 pm

while I don't use any of those.... I know that when using 'debug' the fuses need to be set a certain way and that you need to recompile for 'release' mode to get the PIC to run in the real world.

I'm sure real users will reply with a better explanation..... Smile

Ttelmah · Joined: 11 Mar 2010 Posts: 19543

It is basically saying that the fuses are not being properly set.
Now multiple possible reasons.
First, if the fuses are set, they cannot be erased if you are using LVP.
The 'security' fuse bits can only be erased by a full chip erase with the
full programming voltage.
It looks as if possibly when you were having the programming problems
the configuration may have got set to an invalid configuration.
So, run the CCS Device programmer program, go into the options (top
right), click the little button to open the options window, and in this,
centre top 'use LVP' window, change to 'no'. Then exit the options window
and push the button for 'Erase chip', then go back to your ICD setup,
and try programming again.

mgiuliani · Joined: 30 Mar 2023 Posts: 20

temtronic · Posted: Fri Mar 31, 2023 9:36 am

Maybe do a FULL, total, 100% everything erase and check what the fuses are, compared to the defaults listed in the datasheet ?

PrinceNai · Joined: 31 Oct 2016 Posts: 480 Location: Montenegro

As an idea only. MPLAB gives out a warning which fuses are not compatible with debugging and were forced. If I saw correctly, your chip isn't supported, but maybe MPLABX does the same? If you have a Pickit lying around...

Ttelmah · Joined: 11 Mar 2010 Posts: 19543

Step back.

Forget ICD. First thing to do is write a simple program, and try writing
this to the chip with CCSLoad. If this doesn't work, then there is a problem
with some aspect of the setup. Classic is that the programming cable is
too long. An absolute maximum of perhaps 150mm. You can also use
the diagnostics in CCSLoad, to test all the pins, supply voltage etc..

Have you actually had the chip running?.
How is the system powered?.
How big is the system (power consumption etc.).

Incorrect smoothing, or trying to run more than just the chip from the
ICD-U80, will cause problems.

mgiuliani · Joined: 30 Mar 2023 Posts: 20

No solutions yet. Full erase and reprogram doesn't work. I know the hardware is good. In my original post I forgot to mention that just doing a simple build and run programs the device without any issues, so it's debugging specifically that doesn't work. I'm sure there's something wrong with the fuses/configuration bits but I can't wrap my head around what they're supposed to be set to for my chip for debugging even looking at the datasheets and everything online. No one on my team has debugged with CCS Compiler or my ICD on any of our devices ever, so that doesn't help either. Emailed CCS tech support, hopefully their people have some insider knowledge on what the deal is here.

Ttelmah · Joined: 11 Mar 2010 Posts: 19543

Most of the PC24's have multiple pins that can be used for ICD.
You have to have ICD=n for the ICD pins to be used.

newguy · Joined: 24 Jun 2004 Posts: 1909

Just wanted to offer that when I used the ICD-U80, it was very, very buggy. Take this insight with a grain of salt because that was 5 years ago and CCS may have improved it since then.

I always just use the ICD-U64 because it seems to be way more stable.

mgiuliani · Joined: 30 Mar 2023 Posts: 20

One step forward one step back with CCS tech support. The configuration bit issue is figured out now. In CCS Compiler I had to go to Device Editor under the Tools tab, then in the little window it opens there's a scrollable box in the top right for all the config bits. At the bottom of the list there are 12 RESERVED slots. I had to change the top 2 bytes, which by default for me were always 00, to FF for both the VALUE and MASK column. For example the first reserved slot was 007010 and I had to change it to FF7010. Doing that for all 12 RESERVED slots stopped that issue.

Now I'm back to the firmware verification failing (screenshot of failure window below). When I first had this issue it was because I needed to update my ICD's firmware and CCSLoader, but now it's happening again with them updated. I also can't do a Build & Run successfully either. That fails too.

Programming and verifying the same firmware with a Microchip SNAP in MPLAB IPE works fine, so it looks like the ICD-U80 being buggy is probably the culprit.

I also am using #device ICD=3 instead of #device ICD=TRUE now, which is correct for my device, but the issue persists. Waiting to see what tech support says next.

https://ibb.co/sm3TwPM

Ttelmah · Joined: 11 Mar 2010 Posts: 19543

Try all the other ICD= options.
I've seen quite a few chips where the CCS numbers do not match the
Microchip labeling. So ICD=1 for the PGM3 pins etc..

mgiuliani · Joined: 30 Mar 2023 Posts: 20

mgiuliani · Joined: 30 Mar 2023 Posts: 20

Tech support never got back to me, but I tried downgrading the ICD-U80 firmware (3.57 to 3.22) and trying again. That fixed in and everything works now! I guess the ICD-U80 really is a piece of junk. Everything needed for the solution is edited into the original post. Thanks everyone!

newguy · Joined: 24 Jun 2004 Posts: 1909

Many years ago, just before a customer visit, I dutifully updated everything on our captive system. That consisted of me loading the latest FW into our Load-n-Go, then taking that down to our captive system and actually doing the update.

While I was loading the unit with the latest images, the CCS Loader software alerted me to a new firmware image for the Load-n-Go itself. Without even thinking about it, I updated it.

I then updated our captive system. Everything I updated was bricked. And the customer team had just arrived.

I gave our lead tech 'the look', then ran back to my desk. While I was downgrading the Load-n-Go to whatever image it had prior to the update, I sent CCS a rather terse email. I then learned that the downgrade process had wiped all the target FW images from the unit.

I then reflashed everything and all was fine. When I got back to my desk an email from CCS support was waiting, with an updated FW image for the Load-n-Go.

You honestly don't see that level of service.