Two days wasted... (Product recall)

Do you have a question? Post it now! No Registration Necessary

Threaded View
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: https://media.digikey.com/pdf/PCNs/Microchip/Recall_Letter_AT89LP51ED2_and_AT89LP51ID2_Devices.pdf

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.


Re: Two days wasted... (Product recall)
On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Two days wasted... (Product recall)
On Thursday, April 30, 2020 at 7:54:55 PM UTC-4, Ricky C wrote:
Quoted text here. Click to load it
 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.
Quoted text here. Click to load it
.
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.
Quoted text here. Click to load it
rom Digikey last year.  The defect is that the chips have the EEPROM functi
on totally disabled.  (No shit, Sherlock.)
Quoted text here. Click to load it
51ED2_and_AT89LP51ID2_Devices.pdf
Quoted text here. Click to load it
e surprised by that.
Quoted text here. Click to load it
 code revision required. Problem solved.
Quoted text here. Click to load it
ought through distribution five years earlier.  I had the impression they a
ll had rather massive databases to track parts.  
Quoted text here. Click to load it
lem solved".  Do you have a question or did the direction of the post chang
e between start and finish?  
Quoted text here. Click to load it

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.

Re: Two days wasted... (Product recall)
On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
Quoted text here. Click to load it

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.  

Re: Two days wasted... (Product recall)
On Thu, 30 Apr 2020 17:00:50 -0700 (PDT), George Herold

Quoted text here. Click to load it


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.





Re: Two days wasted... (Product recall)
On Friday, May 1, 2020 at 12:50:01 AM UTC-4, boB wrote:
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
2.
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.
Quoted text here. Click to load it
from Digikey last year.  The defect is that the chips have the EEPROM funct
ion totally disabled.  (No shit, Sherlock.)
Quoted text here. Click to load it
P51ED2_and_AT89LP51ID2_Devices.pdf
Quoted text here. Click to load it
le surprised by that.
Quoted text here. Click to load it
r code revision required. Problem solved.
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Two days wasted... (Product recall)
On Thu, 30 Apr 2020 22:00:36 -0700 (PDT), Ricky C

Quoted text here. Click to load it


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





Re: Two days wasted... (Product recall)
On 5/1/2020 12:49 AM, boB wrote:
Quoted text here. Click to load it

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


Re: Two days wasted... (Product recall)
On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
Quoted text here. Click to load it

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

Re: Two days wasted... (Product recall)
On Friday, May 1, 2020 at 12:02:19 PM UTC-4, snipped-for-privacy@gmail.com wrote:

Quoted text here. Click to load it

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


Re: Two days wasted... (Product recall)

Quoted text here. Click to load it

  Sometimes the delivery agent is the pile of horseshit.

Re: Two days wasted... (Product recall)
On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:

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.






Re: Two days wasted... (Product recall)
On 03/05/2020 12:26, mpm wrote:
Quoted text here. Click to load it

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.




Re: Two days wasted... (Product recall)
On 2020-05-03 09:47, Chris Jones wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it



Quoted text here. Click to load it

Quoted text here. Click to load it



Quoted text here. Click to load it

Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Two days wasted... (Product recall)
On Monday, May 4, 2020 at 2:39:33 PM UTC-4, Phil Hobbs wrote:

Quoted text here. Click to load it

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?


Re: Two days wasted... (Product recall)
On 2020-05-04 17:56, mpm wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Two days wasted... (Product recall)
On Monday, May 4, 2020 at 6:11:56 PM UTC-4, Phil Hobbs wrote:

Quoted text here. Click to load it

Been a rough day here, my apologies.



Re: Two days wasted... (Product recall)
On 2020-05-04 18:27, mpm wrote:
Quoted text here. Click to load it
No worries--sounds like you've been through a lot!

Cheers

Phil Hobbs

--  
Dr Philip C D Hobbs
Principal Consultant
We've slightly trimmed the long signature. Click to see the full one.
Re: Two days wasted... (Product recall)
On 05/05/2020 08:11, Phil Hobbs wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it

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:
http://ww1.microchip.com/downloads/en/DeviceDoc/40001303H.pdf
and look at the errata item 22 here:
http://ww1.microchip.com/downloads/en/DeviceDoc/80000379C.pdf
and item 9 here:
http://ww1.microchip.com/downloads/en/DeviceDoc/80000404K.pdf

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.

Re: Two days wasted... (Product recall)
On 2020-05-06 09:20, Chris Jones wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it

Wow, you guys have really thin skins.

I wasn't calling anyone names--I merely disagree with you about the  
importance of moving errata stuff into the main datasheet.  Making your  
suggestion into company policy would make the documentation mess worse  
rather than better.  As the proverb goes, "Hard cases make bad law."

And it's quite true that we all learn to read the errata before choosing  
a new processor, isn't it?  And anyone who doesn't is, um, inexperienced?

Sheesh.

Cheers

Phil Hobbs

--  
Dr Philip C D Hobbs
Principal Consultant
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline