Parts programmed once, won't reprogram

GeeMott · July 14, 2008, 01:20:10 PM

I have a year's supply of boards that were programmed successfully with FM (thanks in part to your help). Yay. But now they need to be upgraded, and they just refuse to be reprogrammed. I'm using the 89LV51RC2.

Here's the symptoms.
1. It tells me I'm using the wrong device, but I'm okay with that. Still, it's a symptom.
2. It goes through the whole program cycle, but takes twice as long as normal.
3. It fails verify on address 0x0001.
4. When I read the flash contents back, I see that it has changed the byte at address 0x0001 from whatever it was, to 00. Everything else appears to be the same -- unchanged from the original program. Even the byte at 0x0000.
5. If I try to update the bootloader (to eliminate symptom 1) it appears to run the whole thing, but then times out at the end. And I still get symptom 4.
6. If I try to erase the whole chip, it comes back with a success message way too fast, and no erasure.

Of course I need not point out that I used to be able to do upgrades with no problem, been doing it for years, and that nothing I know of has changed, except maybe the batch of the microcontroller. Is there a known problem with a recent batch? Or have I got a serious brain fart going on?

I must also point out that I am not using any security bits or serial number protection. I use 6 clocks on both the original and the upgrade.

Anybody got an idea for some tests I can run, and some way to salvage these guys?

GeeMott · July 15, 2008, 05:32:45 AM

Okay, I scoured the lab and found a few older boards. I can reprogram them just fine. But not the new ones. If I swap out the uC's, the old ones will work in any board, the new ones will not.

The ones that work have this batch code:
FA49-0505
-1G0511 B2

The ones that will not reprogram (and become unusable if you try) have this:
FA55-0236
-1G0627 B2

So I can conclude the problem is not me, and it's not FlashMagic. The question now is, can FM provide me with some kind of workaround? (I can't promise any chocolates this time, I kinda got in hot water over that... But still, you'll help, right?)

Jan Waclawek · July 16, 2008, 12:05:09 AM

Quote from: GeeMott on July 14, 2008, 01:20:10 PM1. It tells me I'm using the wrong device, but I'm okay with that. Still, it's a symptom.

And what is the device (signature) it returns? Which version of bootloader?

JW

GeeMott · July 16, 2008, 07:19:43 AM

The chips that don't work claim to be 8F/91
The chips that do work are BF/91 before updating the bootloader, and BF/9A after.

The bootloader version is P89LV51RC2_V03_UPD_ISP. This only works on the good chips. When I try to update the bootloader on the bad chips, they set address 0x0001 to 0x00 and are rendered unusable.

======================
While pursuing a device signature workaround idea, I find on reexamination that the bad chips give BF/91 (not 8F). I think that was just a misreading on my part earlier, but I'm not 100% certain there.

GeeMott · July 17, 2008, 11:32:54 AM

HI, me again.
On further investigation, I find that the good parts were purchased from Avnet, and the bad ones from PartMiner. What is the likelihood that these are "used" in some way that gives these symptoms? It doesn't seem right to me, because they can be programmed once. Counterfeit, maybe? Is there any good way to tell if these are what they claim to be? I've always considered PartMiner to be strictly legit, so I cast no aspersions, but now I wonder...

Jan Waclawek · July 17, 2008, 12:55:06 PM

Is there any chance to try a different clock (crystal) - say, half of the current value? The rationale being a guess that the troubles started with setting the 6-clock mode, maybe a marginal FLASH controller?

Not that makes you really happy... :-(

JW

PS. Actually, what IS the frequency and the supply voltage?

Jan Waclawek · July 17, 2008, 01:00:34 PM

... it would also be interesting to hear how do they behave on a parallel programmer, including the signature read thereof... Any chance?

JW

erikm · July 18, 2008, 05:22:10 AM

the good parts were purchased from Avnet, and the bad ones from PartMiner.

just a thought, are you erasing the 'protect bits' before attempting to program? It could be that you have used, but good, chips that just happen to have the protect bits set.

Erik

GeeMott · July 18, 2008, 05:37:38 AM

Thanks for taking a stab at this, Jan. No parallel programmer -- I would certainly have tried that long before posting here. The 6-clock mode, power supply and frequency are all highly unlikely because 1) this is a proven design, and 2) the misbehavior follows the chips with the 0627 date code from board to board, while the 0511 chips work perfectly everywhere as well.

Bottom line: I have pretty much decided this is a bad batch from PartMiner, and can afford to eat the cost of replacement. I was worried that this was a systemic problem that had crept into our process, and that I would be unable to build any more. I was just following the old troubleshooting rules of Blame yourself first, and the components last.

Erik, thanks too. According to FM the security bits are clear.

GeeMott · July 24, 2008, 08:16:18 AM

Thought I would post once more on this with the latest, just in case someone else out there is struggling with these dang parts.

If I take a new, virgin part of the "bad" batch (0627 date code) and update the bootloader first, it takes just fine. I can program it and reprogram it many times. If I don't update the bootloader first, I can only program it the one time.

I don't have any virgins left in the "good" batch (0511 date code) but I have a few that have NOT had the bootloader updated, and I can reprogram them at will. All I get is a complaint about the ID not matching. (And I don't mind that -- it makes me double check to see if I have the right one selected).

Still not sure if these are bogus in any way. They seem to work all right, but I'm not stressing them.

Thanks again to all who have stretched their brains on this.

Jan Waclawek · July 24, 2008, 02:00:09 PM

Quote from: GeeMott on July 24, 2008, 08:16:18 AMIf I take a new, virgin part of the "bad" batch (0627 date code) and update the bootloader first, it takes just fine. I can program it and reprogram it many times.

And do you program the x2 (6clk) flag when/after updating the bootloader?
What is the version of bootloader BEFORE updating?

JW

GeeMott · July 25, 2008, 08:07:02 AM

Quote from: Jan Waclawek on July 24, 2008, 02:00:09 PM

And do you program the x2 (6clk) flag when/after updating the bootloader?
What is the version of bootloader BEFORE updating?

JW

Not sure what your questions mean. AFAIK, the 6clk flag is not an option on the bootloader update. I program that when I load in my app. And I have no idea how I would or could know what version of the bootloader is in there.

Jan Waclawek · July 27, 2008, 10:33:11 PM

Quote from: GeeMott on July 25, 2008, 08:07:02 AM
Quote from: Jan Waclawek on July 24, 2008, 02:00:09 PM

And do you program the x2 (6clk) flag when/after updating the bootloader?
What is the version of bootloader BEFORE updating?

JW
Not sure what your questions mean. AFAIK, the 6clk flag is not an option on the bootloader update. I program that when I load in my app. And I have no idea how I would or could know what version of the bootloader is in there.

Well, my idea was, that the problem might be related to the 6clk flag rather than bootloader version. I.e. that you might be update the flash as long as you won't program the 6clk flag.

The version of bootloader should be displayed together with signature when you perform "ISP->Read Device Signature" in FM, on the bottom of that window.

JW