PIC18F6621 fuses

[micro_joe]

I have a design that uses the PIC18F6621.
When I program it using the ICD-40 through the ICD software or the PCW IDE I get the Verification Results window giving me Configuration Fuses errors.
eg Actual= BORV20 Expected = BORV45
Actual = NOPUT Expected = PUT
If I change other fuses I can get errors with those too. I haven't tested all of them.
I have 3 prototypes and have one that works with no problems and two that give this problem.
The code programs ( I have not run it yet) ie I don't get any errors.
I can't work out what is wrong.

If it works with one the software must be OK so it must be the hardware but if this is the case why does it work on any of them.
I don't know enough about the mechanism for blowing fuses to start to debug the problem.

Anyone have any ideas?
I've searched the forum but can't find a thread covering this. I guess it something I've done all there would be loads of threads.

Thanks

[dhorvath]

Hi micro_joe,

I'm having the same sort of problem over here... I'm wondering if it's a cabling issue, as the debugging instructions seem to emphasize checking signal integrity, etc. I have a crappy scope here that doesn't allow me to see the waveforms accurately enough to verify it one way or the other.

I was wondering if you were able to find a resolution to your problem yet? I'm having problems using the ICD-U with a PIC18F6620.

You can email me directly at dhorvath (at) cortex-design (dot) com.

Cheers,

- Dylan

[dhorvath]

Oops! In looking through some other posts, I noticed that some people experiencing similar problems found that their power planes were not entirely routed... that turned out to be the case with me as well. I had not connected my VDD and AVDD lines to the +5V supply.

So even though I was able to program the part, I could not program the fuses. Strange!

As soon as I hooked up the VDD to the power supply, I was able to program the part and fuses properly.

[micro_joe]

Hi dhorvath,

I'm glad you have resolved your problem. It's always good whether it was a simple or complex solution, you can return to the original project and not get diverted.
I haven't resolved my problem.
The prototypes run OK even with these problems. For my customer there shouldn't be a problem.
I do have power on all Vdd pins (4.94V), and good ground continuity on all Vss pins. The signals look good, sharp edges but with a little overshoot ( this could be the scope. I haven't balanced the probes). I'm using the original cable with the end changed to a tyco 0.1" pitch header. The board is 4 layer with power and gnd on the inners.
I've run the test target function in the ICD control program and it passes OK.
I had no problems on a project with the 12F629, blew the fuses without problems.

I've changed the processors on the current prototypes from 18F6520 to 18F6621 and I may have damaged the chips putting them down by hand.

I have to re-do the PCB and build some more prototypes. I hope these turn out with out problems. I may see if I can try the microchip dev kit and see if the exhibits the same problems.

What were the other posts you were looking at? I had a look through the forum but couldn't find anything of relevance. I was probably not trying the correct keywords in the search.

In the mean time I'll have to get some more prototypes build and hope.

Cheers
Andy

[Guest]

Hey joe_micro,

The other posts I was looking at that I thought might be relevant were

http://www.ccsinfo.com/forum/viewtopic.php?t=18761

Not a terribly encouraging thing to read...

Thanks for your feedback! I wish CCS was as quick!

[micro_joe]

Hi All,

I had a chance to test my 18F6621 design on a MPLAB/ICD-2 set up. I loaded the code from the device into Mplab changed a fuse setting ( one of the ones that gave problems) reprogrammed the device. All went OK.
The setup was the same I had been using. I even used the same cable to connect the ICD-2 to my hardware. (I made sure at design time that they were compatable)

Conclusion:
There is problem with the CCS software/hardware.
I'll probalby have to buy a ICD-2 and use MPLAB this to complete my project securely.
If anyone knows any different please post here.

Regards

[micro_joe]

I forwarded the problem to CCS and got a quick response as follows:

"Sir,
After some experiments we found that in some chips(18F6525,18F6585,18F6621 and 18F6680) PUT, BROWNOUT and BORV fuses could not be changed in one step when the clock fuse as set to H4 or E4_IO(using the hardware PLL). You could do it by first writing the required fuses with any other clock fuse other than PLL and then burning the same fuses but with H4 or E4_IO instead.
Say you want to program H4, NOPUT, BROWNOUT, BORV5
then program HS, NOPUT, BROWNOUT, BORV5
the program H4, NOPUT, BROWNOUT, BORV5
Thanks
CCS Tech Support"

I have asked them if it is the programmer or the chip. I await a response.

[micro_joe]

I now have an answer to further questions posed CCS technical support:

"Sir,
You need to do it in 2 steps only when one of the PUT, BROWNOUT or BORV fuses change. So if you do it the first time using some other clock and required fuse and then H4 and required fuses and they get programmed, as long as they(PUT, BROWNOUT and BORV) don't change you can send only one set(with H4). Looks like this is a special requirement by the chips as the other pic18s seems to program fine. We can handle it internally if it is absolutely necessary.
Thanks
CCS Tech Support"

Well this seems like a conclusive answer. If you don't change the fuses then there is little problem after the initial programming using a non H4 setting.
The one thing that still bugs me is how do microchip overcome this or do they hid this in their algorithms.

All in all I very pleased with CCS technical support.

Regards