EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Two days wasted... (Product recall)

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Electronics Design - Two days wasted... (Product recall)

Goto page Previous  1, 2

Phil Hobbs
Guest

Mon May 04, 2020 7:45 pm   



On 2020-05-03 09:47, Chris Jones wrote:
Quote:
On 03/05/2020 12:26, mpm wrote:
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 working 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 code will either hang, or it will proceed even though the
EEPROM write is still in-progress (and will screw-up everything after
that point.)  This is true whether you Page-write, or Byte-write the
EEPROM.  Depending on how quickly you either re-access the EEPROM
(read-or-write), or how soon after you access 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 complete.  You do not need to delay for an EEPROM read.

I strongly suspect the underlying problem is that the Extended RAM
space occupies the same memory address, and is distinguished only
through the use of different OPCODES.  MOVX for EEPROM, and MOV @Ri
for RAM.  Without the aforementioned delay, you end up accessing RAM,
and not EEPROM, with predictable unfavorable results.  (In other
words, the delay for the EEPROM write operation 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
write is in-progress, even though Fig. 3-16 clearly shows that you can.

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

For example,
Figure 3.6 - There is no mention anywhere in the datasheet what "DMEN"
stands 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 EXTRAM.  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 map 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
Application Programming", but the datasheet is utterly silent on what
this means.  It appears nowhere else in the document other than being
the title heading for Section 23.4 .  Furthermore, even if it DOES
mean In-Application-Programming, then the memory map is wrong anyway,
because the setting of this fuse (at initial flash programming time,
and which has been conveniently renamed "In-System-Programming", or
"ISP") has no bearing on the EEPROM operating whatsoever.

Perhaps "IAP" is an acronym from the programming API, which is a
totally separate 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 not 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 memory 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 and 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 something?
(I mean, other than a bad batch of parts, which I guess can happen to
anyone?)

Anyway, this project is done and I'll put a call into Atmel/Microchip
(whoever 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 omissions in its datasheet.


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.


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
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Phil Hobbs
Guest

Mon May 04, 2020 11:45 pm   



On 2020-05-04 17:56, mpm wrote:
Quote:
On Monday, May 4, 2020 at 2:39:33 PM UTC-4, Phil Hobbs wrote:

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.


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?


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
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

mpm
Guest

Mon May 04, 2020 11:45 pm   



On Monday, May 4, 2020 at 2:39:33 PM UTC-4, Phil Hobbs wrote:

> Failing to read the silicon errata is a newbie mistake.

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

Link: https://www.microchip.com/sitesearch/search/Product%20Documents%7CErrata/at89LP51ed2

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.

mpm
Guest

Mon May 04, 2020 11:45 pm   



On Monday, May 4, 2020 at 6:11:56 PM UTC-4, Phil Hobbs wrote:

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


Been a rough day here, my apologies.

Phil Hobbs
Guest

Mon May 04, 2020 11:45 pm   



On 2020-05-04 18:27, mpm wrote:
Quote:
On Monday, May 4, 2020 at 6:11:56 PM UTC-4, Phil Hobbs wrote:

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

Been a rough day here, my apologies.


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


Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

mpm
Guest

Mon May 04, 2020 11:45 pm   



On Monday, May 4, 2020 at 2:39:33 PM UTC-4, Phil Hobbs wrote:

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


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?

Chris Jones
Guest

Wed May 06, 2020 2:45 pm   



On 05/05/2020 08:11, Phil Hobbs wrote:
Quote:
On 2020-05-04 17:56, mpm wrote:
On Monday, May 4, 2020 at 2:39:33 PM UTC-4, Phil Hobbs wrote:

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.


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?


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


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.

Phil Hobbs
Guest

Wed May 06, 2020 3:45 pm   



On 2020-05-06 09:20, Chris Jones wrote:
Quote:
On 05/05/2020 08:11, Phil Hobbs wrote:
On 2020-05-04 17:56, mpm wrote:
On Monday, May 4, 2020 at 2:39:33 PM UTC-4, Phil Hobbs wrote:

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.


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?


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

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.


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
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Goto page Previous  1, 2

elektroda.net NewsGroups Forum Index - Electronics Design - Two days wasted... (Product recall)

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map