Two days wasted... (Product recall)

[Phil Hobbs]

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.

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

 

[Chris Jones]

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.

 

[Phil Hobbs]

On 2020-05-06 09:20, Chris Jones wrote:

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