Two days wasted... (Product recall)

Earlier today, I was going to swallow my pride and ask for help here on something that is supposed to be dirt-simple: Using the EEPROM capability on an 8-bit microcontroller to store four variables that I need to keep track of between power-cycles.

The microcontroller in question is the Microchip Technology AT89LP51ED2.

I tried EVERYTHING. I even spent the good portion of a morning making absolutely sure my Keil compiler was behaving, and another couple of hours on top of that to make sure the chip burner and fuse settings were correct.

Sure enough: There's a product recall affecting the lot we purchased from Digikey last year. The defect is that the chips have the EEPROM function totally disabled. (No shit, Sherlock.)

Link:

formatting link

So there's two day's of my life I'll never get back. Thanks Microchip, and thanks Digikey for letting us know. Maybe Digikey doesn't know who got which inventory? If so, I'm a little surprised by that.

It's just very frustrating. (And so I'm venting a bit..) I moved the project over to an AT89S8253 this afternoon with very minor code revision required. Problem solved.

Reply to
mpm
Loading thread data ...

That's odd. I have received notices from manufacturers about devices I bought through distribution five years earlier. I had the impression they all had rather massive databases to track parts.

You started by saying you were asking for help but finished saying, "Problem solved". Do you have a question or did the direction of the post change between start and finish?

--
  Rick C. 

  - Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Ricky C

I feel your pain. Better sooner than later, anyway. When I've had similar manufacturer mistake issues, I've found digikey to be a good middle man...

George H.

Reply to
George Herold

Not surprising. It's an Atmel part. Not sure if this part was around before Microchip bought them though.

I swore off anything Atmel after a 2003 incident where the ATMega32 (new part at the time) had a 25% or so failure rate running at anything above about 11 MHz. We ran them at their limit of 16MHz

It was a nightmare I could not wake up from for about 1 year. I called it bad silicon. After finally fessing up and $100,000 in company losses, they called it bad testing on their part.

Others around the world had the same issues and Atmel was in denial.

Microchip will hopefully bring them back in line eventually.

Reply to
boB

n something that is supposed to be dirt-simple: Using the EEPROM capabilit y on an 8-bit microcontroller to store four variables that I need to keep t rack of between power-cycles.

  1. > >>

eil compiler was behaving, and another couple of hours on top of that to ma ke sure the chip burner and fuse settings were correct.

from Digikey last year. The defect is that the chips have the EEPROM funct ion totally disabled. (No shit, Sherlock.)

le surprised by that.

r code revision required. Problem solved.

Visited Atmel many years ago when they were getting into FPGAs. Not sure t hey were making MCUs yet. I think this was before flash was on the market so anything would have been EPROM or one time programmable.

The guy we spoke to about their FPGAs mentioned a number of times about how the company was serious about making every penny on every device. I got t he impression it was up to the engineers to assure quality since that is of ten adverse to profit... at least in the short term.

That was the guy who explained to me how time on the tester was often the p rice driver on chips. It wasn't about the silicon die area as much as abou t shortening the test time.

That would seem to tie in with your experience.

--
  Rick C. 

  + Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Ricky C

Complete absence of troubleshooting skills. Unless someone hands you the answer on a silver platter, you're lost.

Reply to
bloggs.fredbloggs.fred

Yes ! Speaking of quality control, to get anybody's attention at the time, I went to their web site and CC'd every "quality" email address around the world with my issues. That got their attention and finally got a response. Their local applications engineer was the only person that came to our facility though.

When we asked about their quality control program, they sent us a one page letter document (might have been double sided ?) that said what their quality control cosisted of. Basically nothing for us to see.

Soon after, when we were talking with Microchip because we were seriously considering the very difficult option of changing processors, they cam and gave us a complete BOOK of quality control procedures that they followed. It was thick and was for end user use. Of course Microchip now owns Atmel. I just hope they can eventually clean up the Atmel half's quality.

I really liked the Atmel AVR processor architecture but I could not trust them after that episode.

boB

Reply to
boB

something that is supposed to be dirt-simple: Using the EEPROM capability on an 8-bit microcontroller to store four variables that I need to keep tr ack of between power-cycles.

.

il compiler was behaving, and another couple of hours on top of that to mak e sure the chip burner and fuse settings were correct.

rom Digikey last year. The defect is that the chips have the EEPROM functi on totally disabled. (No shit, Sherlock.)

e surprised by that.

code revision required. Problem solved.

ought through distribution five years earlier. I had the impression they a ll had rather massive databases to track parts.

lem solved". Do you have a question or did the direction of the post chang e between start and finish?

I was going to just let it go, but it's such a perfect example of how you ( perhaps unintentionally ) get under someone's skin.

No, I did NOT start out asking for help. Thus, my occasional comments about your reading comprehension skills. Go back and re-read the original post. No actual ask.

But more than that, why would you feel it necessary to try to needle over s omething as trivial as that. Your seem to be implying that I can't stay on topic, when it in fact you that have gone off the rail. The entirety of t he post never ventures from the issue at hand. That being: two days wasted in frustration because Atmel (and maybe Digikey too) screwed up.

I think you may have just glossed right over words #4 and #5 in my original post, which of course, sets the entire narrative.

Reply to
mpm

I would counter with complete absence of people skills, or any fact-based evidence as to my actual troubleshooting skills.

And by the way, there's absolutely nothing wrong with someone handing you something on a silver platter. Unless I suppose, it's a heaping pile of horseshit. (But maybe you're into that kind of thing.)

Reply to
mpm

mpm wrote in news: snipped-for-privacy@googlegroups.com:

Sometimes the delivery agent is the pile of horseshit.

Reply to
DecadentLinuxUserNumeroUno

Just going to update this post in case it may help someone in the future wo rking with this particular chip: AT89LP51ED2.

So, I finally got it working right. There are about 10 errors in the most recent Datasheet.

After much experimentation, I have discovered that the EEBUSY flag (EECON.0 ) is totally meaningless. If you test the condition of this flag, your cod e will either hang, or it will proceed even though the EEPROM write is stil l in-progress (and will screw-up everything after that point.) This is tru e whether you Page-write, or Byte-write the EEPROM. Depending on how quick ly you either re-access the EEPROM (read-or-write), or how soon after you a ccess FDATA, your code likely becomes unstable.

The only workaround I have found it so force a delay in the code of about 2 milliseconds to allow the EEPROM write operation (in the FDATA space) to c omplete. You do not need to delay for an EEPROM read.

I strongly suspect the underlying problem is that the Extended RAM space oc cupies the same memory address, and is distinguished only through the use o f different OPCODES. MOVX for EEPROM, and MOV @Ri for RAM. Without the af orementioned delay, you end up accessing RAM, and not EEPROM, with predicta ble unfavorable results. (In other words, the delay for the EEPROM write o peration is somehow entangled with the EEPROM Enable bit at EECON.1)

It appears that you can not turn off the EEPROM enable while an EEPROM writ e is in-progress, even though Fig. 3-16 clearly shows that you can.

There are plenty of additional errors and omissions in the Datasheet relate d to the EEPROM function:

For example, Figure 3.6 - There is no mention anywhere in the datasheet what "DMEN" stan ds for, or how to set it. Also, the external data memory map shows EXRAM = 0 for all but the "64K XDATA" configuration, but they really mean EXTRA M. And, this can only be set by your device programmer. They claim it can be modified while the code is running in the target, but this is complete BS. It simply does not work. You have to rely on the fuse setting during initial flash programming, or the default value ("0") if you're going to ma p EDATA or FDATA into the XDATA space, or just use the whole 64kB for FLASH (Code).

Also in Figure 3.6: They show "IAP = 0", which I assume means "In Applic ation Programming", but the datasheet is utterly silent on what this means. It appears nowhere else in the document other than being the title headin g for Section 23.4 . Furthermore, even if it DOES mean In-Application-Prog ramming, then the memory map is wrong anyway, because the setting of this f use (at initial flash programming time, and which has been conveniently ren amed "In-System-Programming", or "ISP") has no bearing on the EEPROM operat ing whatsoever.

Perhaps "IAP" is an acronym from the programming API, which is a totally se parate document. If so, then the datasheet should explicitly reference the API.

Another thing: And this isn't really an error, per se, but it's more of a "Gotcha!": The EECON register is moved to address 096H in this part, and no t 092H as it is in just about every other 8051 variant in this family that I'm familiar with. So, be sure to adjust that in your compiler / library, as needed.

More crap: Section 3.3.1 claims that all three members in this family (i.e .: AT89LP51ED2 / RD2 / and ID2 will support up to 60-62 kB of external memo ry when using the internally mapped memory -- EXCEPT that they don't bother to mention that the RD2 variant DOESN'T even have EEPROM capabilities, and so the entire 64 kB is actually available. (Atmel does allude to this on the cover page, and nowhere else, that the 4K EEPROM is avail on the ED2 an d ID2. So maybe they get a pass on that, but would it kill them to make it a bit more obvious by at least giving it a passing mention in the section

3 that deals with Memory Organization?) i.e., where it BELONGS!!

This is a mature part, and I've used it in plenty of projects before. I'm not sure why I've never run into all these EEPROM issues before with it , but maybe those earlier projects had outboard memories on I2C or somethin g? (I mean, other than a bad batch of parts, which I guess can happen to anyon e?)

Anyway, this project is done and I'll put a call into Atmel/Microchip (whoe ver makes this part?) and give them the entire list of errors.

You would think a mature part like this would have many fewer errors and om issions in its datasheet.

Reply to
mpm

If it is like the Microchip parts that I have used, they will put the problems into an "Errata" document, and not ever bother to describe any of the problems in the datasheet lest it deter some customer from choosing the part.

One chip that I used had an errata pointing out that it only achieves

10% of the EEPROM endurance that the datasheet claims. They did multiple silicon revisions after that, without fixing that problem, which indicates to me that they can't fix it and never will. Several years and datasheet revisions later, they still claimed the higher number of write cycles in the datasheet, and hide the true number in the errata. Someone more cynical might suspect that they knew about the problem before they wrote the *first* version of the datasheet. Perhaps it helps their sales, in the short term. It does not enhance their reputation in the long term.
Reply to
Chris Jones

One of the things I like about Atmel/Microchip's 8 bit line (when they work properly, which is most of the time at least) is that they're relatively simple devices by modern uP standards, you can pretty much know everything there is to know about an e.g. ATTiny85, the data sheet is only ~200 pages long.

Again, when the silicon is indeed bug-free, they offer up few surprises.

Could I ever know everything there is to know about some mystery-meat

32 bit ARM Cortex-series? Definitely not...

The AT89LP51ED2 looks like it has an 8051 core, uguuuuu why are we still using 8051-derived cores for new projects in TYOOL 2020? "Legacy" apps I understand but....ugh. The reason this bug was obscure is that almost nobody's doing this, if it were a bug in their mainstream lineup it would be on every uP-related forum already discoverable with one Google search

Reply to
bitrex

Well, the silicon errata vary from stepping to stepping (i.e. mask set to mask set), with later versions hopefully correcting the worst errors.

Failing to read the silicon errata is a newbie mistake.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

You do realize that none of the errors mentioned are in the errata. Who's the newbie now? The guy who believes everything he reads (or doesn't read, in this case)? Or the engineer who gets to the actual root of the problem?

Reply to
mpm

I was responding to Chris, not to you. He was complaining about the errata not being in the datasheet.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

...And blindly believing that "the answer" is in the errata is an Old Timer's mistake.

Link:

formatting link

Guess what, Professor? NOT ONE MENTION OF THE PROBLEM WHATSOEVER. (I eventually found the recall notice tucked away on the Digikey website.)

Respectfully, stick that "Newbie" shit up your ass, Mr. Hobbs.

Reply to
mpm

Been a rough day here, my apologies.

Reply to
mpm

No worries--sounds like you've been through a lot!

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

No, I was not. I was also telling mpm not to get his hopes up about his hard work ever being documented in the datasheet. I was also complaining about an unreasonable delay between when they ought to have noticed that they are unable (or unwilling) to fix a bug, in spite of many mask revisions, and admitting to the bug in the datasheet.

If it was a mistake that they were going to fix next revision or at least next all layer revision, then fine, put it in the errata and don't mention it in the datasheet unless feeling helpful. But if it is something they are not going to fix, or can't fix, ever, over multiple all-layer revisions and for probably the entire commercial lifetime of the product, then there is a very fine line between putting the wrong value in multiple revisions of the datasheet over several years, and plain old false advertising.

Here it is: Look at the data EEPROM endurance in Table 26-10 here:

formatting link
and look at the errata item 22 here:
formatting link
and item 9 here:
formatting link

I have copies of the errata from 2013, and I think it has been in there longer than that, so probably more than 7 years.

How long ago would you think it reasonable for them to have discovered the problem without ever mentioning the actual endurance in the datasheet? Before the first datasheet was released? Before the first tape-out? When they chose a process that didn't support the EEPROM cells that would meet the datasheet endurance? When the product was defined?

By the way, the engineer who chose that part did read the errata, and that is how I know about the problem. I've never actually tried wearing one out.

Reply to
Chris Jones

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.