Two days wasted... (Product recall)

[mpm]

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.

 

[George Herold]

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:

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.

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.

 

[Ricky C]

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:

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.

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
- Tesla referral code - https://ts.la/richard11209

 

[Ricky C]

On Friday, May 1, 2020 at 12:50:01 AM UTC-4, boB wrote:

On Thu, 30 Apr 2020 17:00:50 -0700 (PDT), George Herold
ggherold@gmail.com> wrote:

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
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.

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.


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.

Visited Atmel many years ago when they were getting into FPGAs. Not sure they 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 the impression it was up to the engineers to assure quality since that is often 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 price driver on chips. It wasn't about the silicon die area as much as about shortening the test time.

That would seem to tie in with your experience.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[John Doe]

Panties in a bind...

--
Ricky C <gnuarm.deletethisbit@gmail.com> wrote:

X-Received: by 2002:a0c:f8cf:: with SMTP id h15mr1518363qvo.22.1588290890268; Thu, 30 Apr 2020 16:54:50 -0700 (PDT)
X-Received: by 2002:ad4:46b4:: with SMTP id br20mr1599068qvb.62.1588290890128; Thu, 30 Apr 2020 16:54:50 -0700 (PDT)
Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Thu, 30 Apr 2020 16:54:49 -0700 (PDT)
In-Reply-To: <e0e78aa5-2ab3-46a8-9297-2e74b5f2d0b3@googlegroups.com
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=70.33.172.5; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 70.33.172.5
References: <e0e78aa5-2ab3-46a8-9297-2e74b5f2d0b3@googlegroups.com
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <43edaa96-bcd3-4d76-94a9-4cae13854186@googlegroups.com
Subject: Re: Two days wasted... (Product recall)
From: Ricky C <gnuarm.deletethisbit@gmail.com
Injection-Date: Thu, 30 Apr 2020 23:54:50 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader01.eternal-september.org sci.electronics.design:592960

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
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.

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
- Tesla referral code - https://ts.la/richard11209

 

[boB]

On Thu, 30 Apr 2020 17:00:50 -0700 (PDT), George Herold
<ggherold@gmail.com> wrote:

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
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.

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.

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.

 

[Ricky C]

On Friday, May 1, 2020 at 1:14:13 AM UTC-4, John Doe wrote:
> Panties in a bind...

Doe can't seem to get enough of me. You have to wonder why he's thinking of my underwear. Maybe he's in love... ???

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

 

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:

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.

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

 

[boB]

On Thu, 30 Apr 2020 22:00:36 -0700 (PDT), Ricky C
<gnuarm.deletethisbit@gmail.com> wrote:

On Friday, May 1, 2020 at 12:50:01 AM UTC-4, boB wrote:
On Thu, 30 Apr 2020 17:00:50 -0700 (PDT), George Herold
ggherold@gmail.com> wrote:

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
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.

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.


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.

Visited Atmel many years ago when they were getting into FPGAs. Not sure they 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 the impression it was up to the engineers to assure quality since that is often 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 price driver on chips. It wasn't about the silicon die area as much as about shortening the test time.

That would seem to tie in with your experience.

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

 

[mpm]

On Thursday, April 30, 2020 at 7:54:55 PM UTC-4, Ricky C wrote:

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
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.

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
- Tesla referral code - https://ts.la/richard11209

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

 

[mpm]

On Friday, May 1, 2020 at 12:02:19 PM UTC-4, bloggs.fre...@gmail.com wrote:

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

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

 

mpm <mpmillard@aol.com> wrote in
news:56065a9b-ea6e-45ab-96b9-6945fe785af6@googlegroups.com:

On Friday, May 1, 2020 at 12:02:19 PM UTC-4,
bloggs.fre...@gmail.com wrote:

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

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

Sometimes the delivery agent is the pile of horseshit.

 

[mpm]

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.

 

[Chris Jones]

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.

 

[bitrex]

On 5/1/2020 12:49 AM, boB wrote:

On Thu, 30 Apr 2020 17:00:50 -0700 (PDT), George Herold
ggherold@gmail.com> wrote:

On Thursday, April 30, 2020 at 7:24:47 PM UTC-4, mpm wrote:
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.

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.


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.

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

 

[Phil Hobbs]

On 2020-05-03 09:47, Chris Jones wrote:

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

 

[mpm]

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?

 

[Phil Hobbs]

On 2020-05-04 18:27, mpm wrote:

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]

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.

 

[mpm]

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.