PIC 18F8720 not reprogramming

[altanb]

I have a board with a PIC 18F8720 on it and I have been able to in-circuit program the board without any problems until yesterday with the following fuses:

NOWDT,WDT128,HS, NOPROTECT, NOOSCSEN, BROWNOUT, BORV25, NOPUT, NOCPD, STVREN, DEBUG, LVP, NOWRT, NOWRTD, NOWAIT, MCU, NOWRTC, NOWRTB, NOEBTR, NOEBTRB, NOCPB

Somehow starting yesterday my ICD-U will not program the processor going through the whole process and then telling me the verification failed.

When I put the microcontroller into the RUN mode the software that I was able to load into it successfully last time (about 2 days ago) still runs on it.

Any remarks? Thanks,

[rwyoung]

I use the ICD-S20 so this may not be much help.

1) Start the ICD software (ICD.EXE I think) which is the stand-alone programming program. Not the debugger you run from inside the IDE.

2) Click the "Advanced" button on the lower right corner. Then under the Erase Modes section, pick the bulk erase on write. Also unless you absolutely need to program in LVP, pick the 5V only mode under Program Modes.

3) Under the Other Options | Erase/Verify options you can force the part to erase. You might try that once too.

I never use the LVP mode but it is my understanding that under certian conditions, once you set the LVP bit, the only way to reprogram the part is to bulk erase first. I may be confused on this part since I've never even tried to use the LVP mode.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[altanb]

I tried these methods and I got a response from the ICD software that the chip is erased but somehow when I wanted to reprogram my old program was still there

Thanks for the response though...

[rwyoung]

Something else, I always enable the power up timer (PUT).

I guess one thing you could try is to write a small "Hello world" type program or LED flasher. Just enough to tell if you have managed to program the part.

Then experiment with different combinations of settings in ICD.EXE as well as fuse values. Try and come up with the most generic fuse collection possible (check the data sheet for default values and use those).

And another option is to borrow another programmer (say an ICD-2 hockypuck) and try to reprogram your board. Or use your programmer but with a new target board. Also check the condition of your RJ-45 cable and connectors in the programmer and on your target board. Cheap connectors tend to wear funny and will cause you much pain!

Whatever you do, try and change only one thing at a time and keep good notes. That way you won't be CONFUSED later if this happens again.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[Douglas Kennedy]

These 18F8720 chips are pesky. They come from the factory set in LVP mode and for some reason some ( not all) chips are very reluctant to come out of this mode. I find I have to use PICSTART PLUS and a very strong ground even tying the 9v plug on the PICSTART to my board ground to get it to take the first erase and get to 5v mode. They behave after that initial progam. I use both ICDU 40 and ICD_S It may be that you have gotten it into LVP mode.

[TSchultz]

What supply voltage are you using.

I have had a number of 18F8720 and 18LF8720 parts that would not either properly erase, or would not program. After doing some work to try and find out what was happening I found that in many cases some of the protection bits, and in some cases some of the reserved bits were not in the correct state.

There is a problem with the erase function in the ICD, it will isue the few commands required to perform the erase but does not actually know they ran, the parts often fail blank test. In addition the bulk erase command does not erase the configuration fuses.

After speaking with Microchip regarding some of the these issues I was told that due to constraints on the substrate the supply voltage must be 4.5V or greater to guarantee full erasure of the part(s). This is a large problem with the LF parts as the supply voltage is often much lower than this. Microchip is supposed to "fix" the erase successfull message after the erase function.

Carefully check the fuses, including the reserved ones. I have been able to get most of the devices to reprogram after doing a full erase with the pic start, using a small cable to adapt it for ICSP.

Another note make sure all grounds and supply pins are connected and properly decoupled. This MUST include the analog supply and ground pins on these devices or you will have programming problems.

Also make sure your cable and connectors between the ICD and your board are good. If there are intermittent connections resulting in noise spikes you can actually permantly damage the PICs. Also make sure the MCLR pin has nothing "extra" on it, the rise time to enable programming is critical. Even putting a scope lead on it to measure the rise time can impact it enough that the part does not enter "test/program" mode and thus all the erase/programming commands are ignored.

The PIC18F18xx20 parts are indeed a pesky breed and must be very carefully fed and cared for.

[Douglas Kennedy]

Perhaps this is unfair but how difficult is to test these devices and discover these problems before they are sent out in volume. If Microchip knows it is a substrate issue then they also know it is a problem. It's bad enough that it happens but even worse that it gets by testing. One of the first handful of these chips I ever got exhibited this issue. I wasted time assuming it was everything but Microchip quality. Surely Microchip test more than just a single chip. At no time certainly early on did they admit to this problem. They really need to clean house and get back to a rigorous testing program before someone ( mostl likely them ) gets hurt.
It's not like they are sold at a discount because they are untested!

[Yashu]

Verify you have Rev A4 die

Even with this Rev, bulk erase @5V with ICD2 would not reset fuses to default for me on some of the devices. But, of course, I was still accused by uChip "support" of improperly executing the procedure...classic.... yea.yea...right... go away.

I'm using my own custom designed production programmer and luckily was able to solve the issue by simply writing directly to the fuse locations via ICSP (HiVoltage) the desired defaults.

I've reached the 2500 unit mark and they still seem to be functioning in the field. But, like Douglas says, that 8720 black mark will take a long time to fade in my book. It cost me a bundle to cure microchip's problem... with no part replacement policy and not even an apology on their part.

The Atmel AVR's and Thumbs are on my drawing board now.

[TSchultz]

Indeed make sure you have A4 silicon! You can specify it when ordering by adding after the full PIC18F8720 part number. It is unfortunate that Microchip is still supplying A3 silicon and it has some severe problems.

As for erasing the ICD does not always seem able to erase some of these parts. I have had good luck using the PicStart for these subborn devices but even then have had to change a few out as I could find no way to reprogram them.

One of the big problems we had was with protection and then not being able to properly clear the fuses so debug mode could actually be enabled. In some cases some of the reserves config bits were not in a "default" state.

As for other processors this is always a choice. I am very dissapointed in Microchip. Over the years their devices have served me very well. However it is my opinion that the whole 18Fxx20 family should not even be on the market yet, they are prototype parts at best. Everyone I have spoken with that have used them have had problems, some of which are compiler issues (both CCS and HiTech), but most are actually hardware "bugs".

Read all the eratta sheets carefully, and remember that just because a problem is not known that does not mean it does not exist. Over the past 5 months we have lost more that 3 weeks total time troubleshooting issues that in the end seemed to be such hardware problems with the device.

It is really too bad, with the large code space the device(s) lend themsleves very well to a number of applications. And maybe one day Microchip will actually get them fixed. Until then I hold my breath each time I try somehting new on these devices.

[Haplo]

This is not the first time that Microchip fails properly testing their products. Remember the infamous bug the 18Fxx2 parts had when the code crossed 0x4000? When such a hideous hardware bug goes through their testing procedures undetected, I'm actually surprised that we don't see more subtle problems (things like substrate problems) more often.
What pisses me off is that Microchip doesn't really care. I remember once someone said NOP is Microchip's abbreviation for "Not Our Problem".

[Douglas Kennedy]

The problem I have with Microchip is the feeling they give you is that you are the only one with the problem. I hope I am wrong but it looks like when they shoot themselves in the foot they wait until everyone else is covered in blood before warnings go out via an errata sheet. This has to be a management culture issue...unless a recall or at least an on demand defective chip replacement policy is in place there never will be any immediate cost to Microchip. A hear no evil see no evil management will be left to count fewer and fewer customers maybe even blaming unloyal and ungrateful customers for dimishing business. A culture of "we're doing great work but no one appreciates it" is not management ...it's arrogance.
On the other hand Microchip could be the best of a rotten bunch. Does anyone have similar gripes about the competition AVR etc?

[Yashu]

[Haplo]

I don't think Microchip customers are unloyal, actually I think they are a very loyal bunch, and Microchip takes them for granted. Where else have you seen a hardware company dishing out faulty products and treating their customers like crap, and still sell millions?

[Yashu]

--taken verbatim from uChip's "Other PICmicro topics" forum 6/25/2003--

*****************************************************
I can assure everyone who has an interest in this topic that the PIC18F8720 is being used successfully by thousands of Microchip customers in production volumes. If you design within the specifications provided in the datasheet and errata documents, the device will operate as expected.



I have been helping Microchip customers for many years and can tell you that when devices don't perform as expected, people are immediately suspicious of the silicon. However, I can honestly tell you that in 99.999% of the cases, the problems lie with trying to use the device outside of specification or the lack of understanding how the device works.



It is relatively common to get a technical inquiry in which a customer states that a device with one date code works and another does not. To understand this, you must first realize that over time, the production of semiconductors will have process variation that leads to slight changes in electrical behavior. This variation is expected and is captured within the electrical specifications for the device. But, if you choose to use the device outside of the specifications, you may find that one device will work while another will not. This is not the fault of the microcontroller, but rather poor design practice at work.



*********************************

Richard Bratcher

Corporate Applications Engineering Manager

Microchip Technology Incorporated

************************************

--said the spider to the fly--

--duly note the incompetent author's identity and add it to your black list--