EEPROM function confusion

[Curious.George]

Re: EEPROM function confusion

i could be that the programmer used a different supply voltage.
or just clocked it slower.

... or the signal (and power) QUALITY was better (less noise/ripple)
(don't forget GND in this analysis!)
... or the levels on the signals were better (than "typ.")
... or the timing relationships between signals were safer
... or the temperature it was operating at was different
... or...

The question I'd be asking myself is: how do I know that the data I've apparently recovered is actually correct?

[R_J]

Re: EEPROM function confusion

All I know is that in some cases freezing and maybe heating changes the ic enough to make it work. I have done it at least 10 times, sometimes just on the mainboard to see if that was the problem, and in the programmer when what I read did not verify.
It obviously does not change the data, I believe it only effects the mechanism that is used to transfer the data, how it is clocked out.
Or maybe it has to do with the price of tea in China that day

[caphair]

Re: EEPROM function confusion

... or the signal (and power) QUALITY was better (less noise/ripple)
(don't forget GND in this analysis!)
... or the levels on the signals were better (than "typ.")
... or the timing relationships between signals were safer
... or the temperature it was operating at was different
... or...

The question I'd be asking myself is: how do I know that the data I've apparently recovered is actually correct?

The tv worked perfectly after transferring data to new eeprom where as before the tv wouldn't power on unless I froze the eeprom

[dskall]

Re: EEPROM function confusion

To me there seems like two different problems. Straight data corruption. Because I have seen where people just rewrite old chip from working .bin. If you have to freeze chip to get data I would not think that chip is going to rewrite. Correct? Also did not think of unplugging before freezing. Maybe that's why I have no success.

[Curious.George]

Re: EEPROM function confusion

The tv worked perfectly after transferring data to new eeprom where as before the tv wouldn't power on unless I froze the eeprom

That's specious reasoning. It doesn't mean that you recovered THE data from the old EEPROM but, rather, managed to get A set of data that allowed it to get past whatever was preventing it from powering on, previously.

Had the TV been designed better, it would have noticed the EEPROM contents "didn't make sense" and would have overrode them (trying, first, to overWRITE them) with a set of sensible defaults. The fact that it refused to power on suggests the developer assumed that was a "can't happen" condition (despite the fact that it obviously DID happen!) and didn't take precautions to guard against it.

[Curious.George]

Re: EEPROM function confusion

To me there seems like two different problems. Straight data corruption. Because I have seen where people just rewrite old chip from working .bin. If you have to freeze chip to get data I would not think that chip is going to rewrite. Correct? Also did not think of unplugging before freezing. Maybe that's why I have no success.

Its hard to know the specifics of the particular failure -- without documentation of the EEPROM's intended contents, actual contents and how the software would react to those actual contents.

As few as one cell in the EEPROM could have failed preventing anything other than a particular bit value from being stored (or recovered!) from it -- while the balance of the device could have been intact. The role that hypothetical "bit" plays in the actual device's operation would depend on the code that references it.

Imagine, for example, there is a set of three options that are encoded into 2 bits (because the developer was "cheap" and assumed things never fail).

• 00 = chocolate
• 01 = vanilla
• 10 = strawberry

Imagine "strawberry" (10) is currently selected and the selection wants to change to "vanilla". The software dutifully writes "01" to those two bits -- but, the leftmost bit (MSb) happens to have failed "stuck at 1". So, what actually gets stored is "11" -- which is "undefined".

If the developer fails to verify the write performed as intended (by reading the bits back after writing them), then the "11" persists -- until the next time the software needs to access those two bits. When it does, it encounters "11" and doesn't know how to handle it (crash!).

There's no way for the software to know if this was a "01" or "10" that erroneously got stored as "11". Or, a "wear error" that has caused enough charge to leak from either of those combinations (or even "00"!). Or, if the device has just DIED!

[R_J]

Re: EEPROM function confusion

Its clear you do not understand how these ic's work. Its not the data area that has the problem, it is most likely the serial interface that goes intermitint, or maybe the clock generator or any other area except the MEMORY AREA.

Here is a block diagram of one of the ic's used in tv main boards

[dskall]

Re: EEPROM function confusion

I would think if the data got corrupted you would have no success at freezing to recover.

[R_J]

Re: EEPROM function confusion

dskall, you are correct, thats why somtimes this does not work and we have to find a bin file from a working tv. that data might still be there but it can't be read out

And the tv must be unplugged first because as soon as it is pluged in and the microprocessor reset happens, thats when the flash is read. freezing it after will have no effect because at that point the processor is just sitting there dumb.
And it may not work the first time, try freezing again, let it sit a few seconds to really get cold, then plug it in and try.

[Curious.George]

Re: EEPROM function confusion

Its clear you do not understand how these ic's work. Its not the data area that has the problem, it is most likely the serial interface that goes intermitint, or maybe the clock generator or any other area except the MEMORY AREA.

Here is a block diagram of one of the ic's used in tv main boards

And, you're claiming that all of the LOGIC that is cast in polysilicon is the problem, not the electrons that happen to be trapped in the gates? You do realize how silly that is...

Hint: read up on EEPROM failure modes and see if it mentions "serial interface" ANYWHERE in ANY of the numerous documents published on the subject (please provide references to any such documents that you find!). I'm sure those of us who've been designing with nonvolatile memory technologies (ROM, EPROM, EEPROM, FRAM, EAROM, BBSRAM, core, WAROM, MNOS, etc.) will be delighted to know that we've been looking for failures in the wrong places, all these years...

Then, pick up a copy of Meade/Conway (or similar) and get a feel for what goes into chip geometries to understand how relatively UNLIKELY they are to magically fail (when contrasted with stored charges).

Finally, lookup "Occam's Razor".

But, then again, maybe TV's are so incredibly different than everything else that uses these technologies!

[Curious.George]

Re: EEPROM function confusion

I would think if the data got corrupted you would have no success at freezing to recover.

The characteristics of semiconductor devices vary with temperature. You are trying to sense the number of electrons trapped in a polysilicon structure (a "floating gate") within the device (a FET). So, the characteristics (time, temperature, voltage) of the storage structures AND the sense/control electronics come into play.

Think of each cell as a little capacitor with EXTREMELY low leakage. You "fill" these capacitors with electrons during an ERASE cycle. Call the filled capacitor a '0' datum. Then, you selectively suck out the electrons from those cells that you want to represent '1' data in the WRITE cycle. Those cells that you didn't "drain" will remain 0's.

[You're actually storing the electrons on the "floating" gate isolated (and insulated) inside the FET's structure]

To READ the contents of the cell, you are essentially trying to determine if it is "holding" electrons, or not. Of course, this isn't an all-or-nothing proposal. There is a threshold above which you conclude "yes it is holding" and below which you decide "no, it is not".

But, you can't COUNT the electrons. Instead, you apply a threshold voltage and use that to determine how much current flows through the cell (governed by the amount of stored charge impeding its flow!)

Yet, none of these voltages are absolutes. They vary with temperature and other operating conditions imposed on the chip. OTOH, the number of electrons on a particular gate remains unaltered (in the short term) -- cooling the device doesn't magically add/subtract electrons to this INSULATED, FLOATING structure. So, altering the voltage, access time or temperature changes how the circuit responds.

[Just like overclocking a particular PC won't work at ALL temperatures and power supply voltages]

If you're operating the device in its stated operating conditions, then the device's design ensures that you get out what you put in. (there are other "process variables" that are pertinent to the manufacture of the semiconductor but the manufacturer hides those details from you)

But, these "capacitors" aren't perfect -- they rely on man-made substances that have real (not infinite) resistances, impurities, etc. So, the electrons trapped do leak, over time. Write an EEPROM and put it on a (cool!) shelf and, eventually, the data will degrade. Put it in a piece of equipment running 24/7 and it will degrade faster. Put that piece of equipment in a warm oven and faster still!

[Note that this is ignoring the effects on the rest of the sense and control circuitry inside the device; just the memory cell, itself.]

Every erase/write operation (even if not to the cell in question) disturbs the charge stored in "nearby" cells -- because those ~20V write/erase pulses aren't infinitely insulated from the cell! The same is true of read cycles, though to a much lesser extent.

[These actions also degrade the physical integrity of the individual cells as they chew away at the insulating layers within the cells -- sort of like high current pulses burning holes through the electrolyte layer in capacitors]

Unlike other memory technologies, FLASH/EEPROM need active management to maintain the integrity of their data. A controller acts as the intermediary between the raw storage array and the eventual consumer. The controller can sense "how much" of a '1' or '0' is stored in a particular cell and rewrite the cell if it senses degradation (the interface at the pins of the device only report '1' or '0' so this information isn't directly observable, there). Or, move the datum to another place (like remapping defective sectors on a hard disk in a way that is hidden from the interface connector) when that cell appears to be "wearing out".

This is an explicit acknowledgement that the storage mechanism is inherently dubious and subject to degrade (why put that extra silicon in a device if it isn't needed?)

[R_J]

Re: EEPROM function confusion

Is this guy for real? Seems like one of those people that love the sound of their own voice. Stick to reading your books, we'll stick to doing the repairs.
Goodnight Sheldon

[dskall]

Re: EEPROM function confusion

But isn't corruption the changing of data the device holds?

[Curious.George]

Re: EEPROM function confusion

Is this guy for real? Seems like one of those people that love the sound of their own voice. Stick to reading your books, we'll stick to doing the repairs.
Goodnight Sheldon

"I froze several of them and they seemed to work. I don't know why. But, the guy who designs these sorts of things for a living obviously doesn't know what he's talking about (and he makes me feel so small and incompetent!)..."

Typical internet clown.

<plonk>

[Curious.George]

Re: EEPROM function confusion

But isn't corruption the changing of data the device holds?

"Corruption" is a misleading term. All you can deduce is that the product that relies on that device is acting as if some of the data that it retrieved was incorrect. You have no way of putting the product in a 'scope loop and watching repeated, successive reads of that location.

And, the software didn't bother trying multiple reads -- what would be the point? If the data isn't good then how do I know that the next read (of the same datum) will be any better?! (see my up-thread comments on how software should treat persistent data)

The data can change (or appear to change) because:

• the software wrote the wrong data, previously (i.e., a bug)
• the data degrades through normal use of the device (i.e., read disturb, write disturb)
• the device deteriorates through normal use (e.g., the dielectric that insulates the floating gate -- and keeps the electrons trapped -- wears out from use)
• the environment in which the device is operating destabilizes or moves out of the guaranteed operating conditions for the device (i.e., die temperature, power supply voltage changes, noise on signal lines, timing violations -- anything that isn't specified to conform with the datasheet's parameterization)

Remember, you don't know everything that a chip has experienced before a particular failure. And, in most cases, the system employing the device is very complex -- you can't just take a peek at what it is doing NOW and extrapolate, from that, what it has done in all the time prior.

If replacing a device "fixes" the problem, it can be because:

• the "data store" portion failed
• the control and sense logic failed
• the environment had changed so the device is struggling to work (remember, the device WILL give you a datum... it doesn't guarantee that it is correct if you've violated its operating conditions!)
• the software bug hasn't yet struck again (to clobber the datum/data)

The Industry has already made it very clear that the problem lies in the data store for chips that fail. And, the environment (hardware and software) issues that can exacerbate that failure (temperature, voltage, byte-mode writes, write frequency, erase recovery time, etc. -- none of these affect the reliability of the "control and sense" logic) on a temporary or permanent basis E.g., operating at elevated temperatures and voltages and byte-mode writes and frequent accesses can accelerate the chip's failure (by wearing out the data store, not the control/sense logic).

You can shrug and feel good about a set that turns on -- now. And, wonder if it is going to suffer the same fate, later, cuz all you did was replace a device that may have been operating properly -- but in a flakey environment -- with one that seems to be more tolerant of that environment, for now! Hey, maybe you'll be able to get TWO repair fees for the same set!!

(Sort of like clowns that replace fuses BEFORE figuring out why the fuse blew in the first place. "Hey, maybe I'll get lucky and it was just a defective fuse??" Yeah, right... everybody knows there's been a rash of defective fuses manufactured!! "Gee, look at that! A second defective fuse fresh out of this bag of brand new fuses!")

And, cuz it seems to work (but you don't know why), you'll add it to your bag of tricks -- and scratch your head when it doesn't solve the problem (cuz all you're doing is throwing possible fixes at a problem without understanding why -- or even IF -- they work)

[By contrast, when you are designing something, you have to know what WILL work and what DIDN'T work -- lest you make a costly mistake for your company!]

But, hey, listen to the clown, he's convinced he's got the answer (without being able to back it up in any way). If it seems to work, lets assume that it is the reason for the success. And, if it doesn't, then it must have been some other problem (surely not a refutation of the technique! ).

Sure glad that professionals don't rely on such techniques! ("Hey, Doc... are those LEECHES in that jar???" )

[dskall]

Re: EEPROM function confusion

Thanks, BTW leeches do have medical uses.

[Curious.George]

Re: EEPROM function confusion

Thanks, BTW leeches do have medical uses.

Lots of things have medical uses!

But, my reference was to the early belief that "bloodletting" would release the "bad humours" from the body and enable a recovery -- if the patient survived, it was seen as PROOF of the theory. And, if the patient DIED, it was because of some other problem.

I.e., the outcome was not related to the use of leeches at all!

[Watch people playing slot machines and listen to their cockamayme rationalizations for their behaviors ("priming" the machine, "she's ready to hit", etc.) when, in reality, there can (by law) be no way of predicting the outcome of any game/pull-of-the-lever. In fact, when designing such "amusement devices", we have to go to great pains to prove this -- to the regulators AND to the folks who will ultimately buy the games (no one wants to discover that there is a way that players can reliably "beat the house" -- when THEY are The House!)]

[caphair]

Re: EEPROM function confusion

This got me wondering, does anyone remember “chips” sold in the 90s that programmed the older analog cable boxes to get all the channels?

Were these chips simply altering the eeprom in those boxes?

That’s what actually got me into electronics at the time. I thought it was so cool you could do that when people spoke about it

[Curious.George]

Re: EEPROM function confusion

This got me wondering, does anyone remember “chips” sold in the 90s that programmed the older analog cable boxes to get all the channels?

Were these chips simply altering the eeprom in those boxes?

That would depend on how the "box" implemented the access control.

Ages ago, designs (in general) were pretty naive -- they figured obscurity was an effective deterrent. E.g., the old AT&T credit card system allowed you to "make up" a valid credit card (telephone) number from any phone number just by knowing how the "check digit" was computed. Once that information got loose, in the wild, anyone could use any phone number to bill calls that they were making (from a "third" phone).

Amusingly, this sort of thing is still common, nowadays -- knowing how to patch programs or set up "hidden" registry entries to enable features that cost more... IIRC, there are some "server" versions of older MS OS's that differ from their retail counterparts just by a registry setting, or two. And, MS's "fix" for this problem was to periodically watch for any changes to those registry values and automatically change them back! (so, change them when the OS isn't looking -- isn't RUNNING -- and you've bypassed their defense!)

Now, things that rely on "shared secrets" go to greater lengths to make those secrets less universal (e.g., you might discover the secret to unlock YOUR box but that knowledge doesn't help you unlock your friend's "identical" box!).

Other designs acknowledge the transient value of this sort of secret and make it very easy for the secrets to be changed.

I worked on a commercial/industrial (door) lock system that was used in hotels and other "large" (as in "lots of doors") establishments. A door is just a combination lock -- the combination is either mechanic (an old fashioned "key"), electronic (electronic key or mechanical key read electronically) or interactive (user pushing buttons).

These sorts of large establishments typically have multiple users for any (and every!) door lock:

• hotel manager (access everything?)
• hotel guest (access this room plus any of the locked "common areas")
• housekeeper (access a preassigned group of rooms)
• janitor (access a potentially larger set of rooms)
• maintenance folks (electrician, plumber, etc. probably access most rooms)

But, you know, for a fact, that some number of "guests" will leave without remembering to drop off their "key" at the front desk. As a result, the NEXT occupant of the room they had occupied is now vulnerable to a malicious return visit by this previous occupant. Likewise, if one of your housekeepers quits (dies?), all of the rooms authorized for that credential are at risk -- until you can reclaim the credential.

[And, that ignores the possibility of counterfeiting any of these credentials!]

Sure, you can levy a charge against a guest (or employee) for "failure to surrender key". But, that still leaves you vulnerable for some period of time and in need of re-keying all of the affected doors! (remember, you have to rekey the doors so only the "compromised" key is invalidated -- without affecting any of the other keys that are still valid).

So, you design the lockset in such a way that it can be rekeyed by unskilled (though TRUSTED!) staff without fancy tools and in a very short amount of time (seconds). With large key spaces, you don't have to worry that the new keying will suddenly make an old, invalidated key functional, again!

[Ever wonder how many vehicles your OLD car key would work in?? ]

These criteria also make it easier to protect against someone PUBLISHING your "secrets" (allowing other folks to manufacture keys without your involvement).

[ramondo]

Re: EEPROM function confusion

HIJACK ALERT?? I have a question about how an EEPROM is programmed at the factory; is it done with firmware installation or does it LEARN at first power up? Can we duplicate this process at home?
PS I WOULD like to hear from Curious.George as we all cannot be fixers extraordinaire.