Messages

There is no code that accesses the IAP stuff.  If that is happening it is by the most unlikely random chance. I don''t use the watchdog, maybe it is time to put that in at least as a diagnostic.  I am checking the VCC and reset generator as you suggest, but this is so intermittent and hard to reproduce, it's not showing anything.

But there is one more straw to grasp at.  It's possible that these parts were programmed with the Flash Magic tool set to the -RC2 part by default, rather than the proper -RD2.  Could that possibly affect the retention of the program???

Another real hair-puller for me.  I have a mature, stable design based on the 89LV51RC2.  When that part was discontinued, I moved to the -RD2.  When I program them with the same old code, they work fine -- at first.  Some of them (3 so far out of 10) just spontaneously erased themselves after a few days.  I even tried setting the security bit and adding a serial number as write protection, to no avail.  I put the failed board on Flash Magic, and saw the security bit was still set, but the part was otherwise blank.

Suppose I have a stack leak or wandering program counter in my code, that was never found because the RC2 had less program space -- something that was benign before, but now isn't.  Is it possible to access a built-in "erase all" subroutine by accident?

Maybe you have the same problem I had:
http://forum.flashmagictool.com/index.php?topic=3497.0

The solution was (and still is), I have to update the bootloader BEFORE I program the device the first time.  If I fail to do this, the part programs only once.  Then if I need to update it, it goes into a little box labeled "parts not worth keeping."

I haven't had experience with this exact part, but I know that others in this family can be very finicky.  If you do the wrong thing one time, there is no way to recover.  I have had symptoms similar to yours: getting back the U's but not entering ISP mode, etc.  It is possible, just possible, you ruined your batch of 10 early on, and nothing after that will work.

First thing I learned the hard way: always start FM and select the correct part before applying power to the board.

Second, ditto: on a fresh chip, always update the bootloader first thing.

Other than that, your trick with the supply voltage is VERY suspicious.  There really shouldn't be a difference between operating at 4.96 or 5.05.  Are you sure your power is clean and has plenty of current available?

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.

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.

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.

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...

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.

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?)

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?

Okay, a box of Godiva truffles is on the way. They are slow shippers so you can expect it just after Thanksgiving.

Now here's the next question, am I going to have to upgrade the bootloader on every unit I produce, before I can burn my application code?  I don't see any notes about  "units before a certain date code" or anything.

Not that I know of. It is possible that something was exchanged at the beginning of the evaluation process (this is a new design).  I didn't put myself into "troubleshoot mode" until I started having trouble.

(Time passes.)

Acting on your hint, I replaced the uC with a fresh one.  Hooray it did program! (Although it didn't like the device signature.)  So it was a bad or corrupted device?  Is it redeemable?  Did I do something to ruin it which I need to avoid in the future?

I've been beating my head against this for 2 days, and you put me right that quick. Can I send you some chocolate?

Thanks, Andy, for the quick response.

However, that's what I'm already doing. When I see the string of U's (4.808 KHz square wave at 9600 baud), FM tells me to reset, and I do.  TXD won't budge.

uC: P89LV51RC2FA, PLCC44 pkg
VCC = 3.3V at pin 44 verified
VDD = GND at pin 22 verified
EA pin 35 at VCC verified
PSEN pin 32 is floating
XTAL1 pin 21 has 12.5 MHz square wave, 3.3v/GND
XTAL2 pin 20 floating
RST pin 10 has 10uF to VCC, 8250 ohm to GND
TXD pin 13 is, at the moment, floating

Start FlashMagic, see 4.808 KHz square wave, 3.3v/GND at RXD pin 11.
Bring RST to VCC (approx 2 nS rise time) for a time anywhere from 400 mSec up to several seconds.  Fall time is approx 100 mSec.

Nothing EVER appears at TXD, which stays at 3.3v. (Once it responds, I will reconnect it to my 232 driver and go from there).

I don't imagine the problem is in FlashMagic, but What Am I Doing Wrong?