Attempting repair EEPROM - Voltage increase method

[Tantratron]

Hello and hoping you are all OK with Covid-19 actual times.

I've decided to start this new thread following a specific suggestion user @SaabFAN regarding how to extract data stored in a failed EEPROM https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2897982/#msg2897982

If the EEPROMs are damaged and not working correctly, you might be able to read them by increasing the voltage a bit until you finally get the data. That method worked for me with an older parallel EPROM that had started to exhibit bit-errors. With the voltage cranked up to 6,5V I was able to reliably read the chip and re-writing it. After that the device with that chip in it didn't crash any more.

At the end of this long thread I've been finally able last week to restore the TDS540C Acquisition board by installing two new EEPROM (24C02) after de-soldering the two failed one (maybe one is OK but my TDS540C would fail upon reading the first one). Then today I've soldered Quick&Dirty different wires between the 2 failed EEPROM which will be connected to my arduino MEGA using the I2C library to attempt reading them.

However I'd like to know from those of you knowing this technique of increasing the voltage if it just concerns the power supply of the EEPROM ( pins 4 and 8 ) ?

I ask this because the SCL and SDA output of the arduino MEGA are 5V so it will be impossible to push to say 6V or 6.5V unless using a fast DC-DC converter.

N.B. About the Pin 7 which is the WR enable of the EEPROM, here I've directly solder to +Vcc to make sure I'll not write by mistake with my arduino code.

In other words, is it OK to use 5V bus modulation on SCL and SDA whereas the rest of the pins would powered say by 6V to attempt reading their content for re-flashing new EEPROM's later. Any suggestions or critics for those who have done this recovery VOLTAGE technique would be appreciated.

As a reminder, if I can recover their content which are factory calibrated value unique to each acquisition tektronix TDSxxx oscilloscope, I could save the time to not re-calibrate my TDS540C.

Thank you, Albert

[MadTux]

Reading with modified voltage levels doesn't work reliably, from my experience.
If EEPROM has leaked empty, data is gone, no matter what.

Find another TDS540C and clone the EEPROMs from there. Another reason why I stay miles away from new stuff, with lock bits and other crap, that makes your life hard. Once the data is gone on those, you essentially have an expensive brick, because of a few missing electrons on a floating gate.

[SeanB]

Might work if the cells are just at the threshold, and often you find older programmers wouls write the EPROM at 5V, and then run 3 vrerify passes, the first at 5V to see it was programmed, the second at 4V5 to see if any cells were weakly programmed, and a third at 5V5, to see if threshold shift would cause an error.

However, with the common program alogrithm doing each write at 1ms cycles, and a verify after write, till the cell programs, followed by a 3 times that time write for each cell, you find most are fine. This was a big speed increase over the old method of a 50mS pulse per cell, as most modern devices program in 5ms or less, so instead of doing 20 bytes a second you could go up to 200, saving a lot of time on big devices.

[wraper]

Beside voltage you could play with temperature.

[SaabFAN]

With the parallel EPROM both the supply-voltage and the signal levels on Address and Data-Lines went up to 6.5V.

I would try to increase the voltage in steps. First 5.5, then 6 then 6.5 and if the readout is still not consistent, go all the way up to 7V.

To keep the high voltage from the input-pins of the Arduino, you'll have to use either series resistors and rely on the ESD-Diodes to dump the excess voltage to the 5V-Rail of the Arduino, or you build up a i2c Level-Shifter with 2 MOSFETs.
You basically need to increase the signal levels on the i2c-Bus to the supply-voltage of the chip with the highest supply-voltage to satisfy its HIGH and LOW-Level thresholds.

And as wraper said: Try playing around with temperature. Any means to improve signal to noise-ratio inside the chip will help make the readout more reilable if the charge on a gate is just below the threshold or some transistors inside the chip are on the verge of failing.
If there's actually something broken inside, or the gate-charges are depleted too much, then the data is gone of course.

[Tantratron]

Find another TDS540C and clone the EEPROMs from there. Another reason why I stay miles away from new stuff, with lock bits and other crap, that makes your life hard. Once the data is gone on those, you essentially have an expensive brick, because of a few missing electrons on a floating gate.

That is what I did yesterday thanks to my 2nd TDS540C https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2997196/#msg2997196 but it is not certain optimal performance unless full calibration. There is a consensus the initial CalData in the EEPROM were factory obtained hence my attempt to recover the failed EEPROM

[Tantratron]

With the parallel EPROM both the supply-voltage and the signal levels on Address and Data-Lines went up to 6.5V.

I would try to increase the voltage in steps. First 5.5, then 6 then 6.5 and if the readout is still not consistent, go all the way up to 7V.

To keep the high voltage from the input-pins of the Arduino, you'll have to use either series resistors and rely on the ESD-Diodes to dump the excess voltage to the 5V-Rail of the Arduino, or you build up a i2c Level-Shifter with 2 MOSFETs.
You basically need to increase the signal levels on the i2c-Bus to the supply-voltage of the chip with the highest supply-voltage to satisfy its HIGH and LOW-Level thresholds.

And as wraper said: Try playing around with temperature. Any means to improve signal to noise-ratio inside the chip will help make the readout more reilable if the charge on a gate is just below the threshold or some transistors inside the chip are on the verge of failing.
If there's actually something broken inside, or the gate-charges are depleted too much, then the data is gone of course.

Thanks for guidance so I wonder if I might not use some spare IL610 (NVE Corporation) which I had from another old power electronics project, they can accept VDD up to 7V.

As for the thermal play suggested by @wraper I'll try this as well since I've lot time now due to confinement.

Thanks again, Albert

[amyk]

I suspect this method will only work on the old parallel EEPROMs which have a pretty direct path between the power supply and reference amps; newer and especially serial ones will just get damaged by the higher voltage or be ineffective because they have internal regulators and run the memory array at a lower voltage than their inputs.

[Tantratron]

Please find an update of this process, attached my Quick&Dirty arduino MEGA and both EEPROMs taken from the TDS540C along with reading I2C attempt results of both chips (U1052 and U1055).

It seems confirmed why the TDS540C would fail during the self-test, namely the ASIC attempted to read U1052 but no response so it will never read the 2nd one and declare a Processor fault. My arduino sketch (see attached result and code) attempts to read each chip independently with a partial good news, the 2nd chip seems to have valid data. However the 1st chip is failed under +5V bus from the arduino so same as when it was inside the TDS540C returning always FFFFFF's.

N.B. I've not figure out for the moment an arduino sketch to display fully HEX as any HEX editor which explains sometimes missing MSB zeros. The problem is that arduino IDE does not offer the possibility to create, write or read files directly on PC, Mac...

Now I wonder if really it does make sense to play with the higher voltage and or thermal method suggested because it seems not sure to be really the memory gone. The X24C02 has an I2C serial interface with different blocks prior to serialize the reading of its internal parallel 256 octets memory. As a reminder the analysis of both @ragge https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2898054/#msg2898054 and @madao https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2899212/#msg2899212 showing the protocol failure wether memory was read or not read.

When looking at the attached datasheet of the X24C02 (functional diagram page 1), the question is how to hack or verify or force the I2C control logic front end to respond wether there is valid or not valid memory stored in the 64x32 E2PROM silicium.

Thanks if any hints or suggestions, Albert

EDIT: I've modified slighty the arduino code to have clear tabulation and non missing zeroes (see attachement screenshot added)

[SaabFAN]

The only way to find out if there's data inside the memory is to write an address to the chip and then issue a read command.
If you can see an "ACK"-Signal from the chip on the i2c-Data and Clock-Lines, the control logic and state machine of the chip are working. If not, they're toast.

If the control logic and state machine inside the chip are ok and the memory-array is driven directly by Vcc, increasing the voltage might yield you the necessary signal to noise improvements to read addresses that are just marginally below the threshold. If the memory-array is driven from an internal voltage regulator of the chip, then amyk is right: Increasing the voltage won't help and probably just burn out the chip.
Given the fact that the chip is able to generate the high voltage for programming the memory-array I'd say it is highly likely that the sense amplifiers and all the circuitry surrounding the memory array are supplied by an internal linear regulator and a charge pump. So increasing voltage is most likely not an option.

In addition to that, what the chip is outputting (every single byte sitting at 0xFF) shows to me that either the chip is bad or the memory got actively erased. If it just had lost its content I would expect random values and not all 0xFF, which is the unprogrammed state of each byte inside the memory-array of the chip.

I would throw both chips away at this point and just start calibrating the scope.
If you don't have a signal generator capable of 1GHz, you can build one from a ADF4351 signal source, a step attenuator, amplifier-module and an Arduino. If you care about harmonics in the signal, add a filter-stage (see my Signal-Generator-Thread for that - I have a few Filter-Board left over btw.).
That's a much better investment of your time than trying to revive a dead / trying a data-rescue on an i2c EEPROM.

[shakalnokturn]

Here's the way I'd go about it in your situation (with the equipment I have):
Start by comparing I/V curves of a good 24C02 and bad one, each pin relative to ground then Vcc using a scope with component tester. (Or Huntron tracker)

In case of differences without internal shorts or no differences at all, try playing on temperature while reading.
In case of an open pin, that could be due to a broken bonding also try playing with temperature and/or physically clamping the package while reading.

In case of a shorted I/O pin it's rather bad news, close to no chance of recovery but as it's dead anyway you could attempt to fuse the short ramping the current up into the short but keeping right polarity and maximum voltage.

[Tantratron]

The only way to find out if there's data inside the memory is to write an address to the chip and then issue a read command.
If you can see an "ACK"-Signal from the chip on the i2c-Data and Clock-Lines, the control logic and state machine of the chip are working. If not, they're toast.

If the control logic and state machine inside the chip are ok and the memory-array is driven directly by Vcc, increasing the voltage might yield you the necessary signal to noise improvements to read addresses that are just marginally below the threshold. If the memory-array is driven from an internal voltage regulator of the chip, then amyk is right: Increasing the voltage won't help and probably just burn out the chip.
Given the fact that the chip is able to generate the high voltage for programming the memory-array I'd say it is highly likely that the sense amplifiers and all the circuitry surrounding the memory array are supplied by an internal linear regulator and a charge pump. So increasing voltage is most likely not an option.

In addition to that, what the chip is outputting (every single byte sitting at 0xFF) shows to me that either the chip is bad or the memory got actively erased. If it just had lost its content I would expect random values and not all 0xFF, which is the unprogrammed state of each byte inside the memory-array of the chip.

I would throw both chips away at this point and just start calibrating the scope.

Again the scope view traces of both SDA and SCL when the EEPROM were soldered on the TDS540C did show no ACK. This probably means the control logic, state machine or the SDA output transistor (BiPolar of Mosfet...) are failed. Wether reading the memory or writing the memory, the arduino code (see below attached extract of my today's code) will call Wire.endTransmission(). The result is always 2 when I attempt reading which means NACK confirming what I did probe back few weeks ago inside the TDS540C ( see error code of Wire.endTransmission https://www.arduino.cc/en/Reference/WireEndTransmission )

Code: [Select]

byte readAddress(byte i2cAddress, int address)
{
  byte rData, TransmissionStatus;
 
  Wire.beginTransmission(i2cAddress); 
//  Wire.write((int)(address >> 8));   // MSB
  Wire.write((int)(address & 0xFF)); // LSB

/*  Wire.endTransmission(); 
  Wire.requestFrom(i2cAddress, 1);*/

  TransmissionStatus = Wire.endTransmission();
  if(TransmissionStatus == 0){; 
    Wire.requestFrom(i2cAddress, 1);
    rData =  Wire.read();
  }
  else rData=TransmissionStatus;
  return rData;
}
It just happens the 0xFF data read is just the arduino routine return and not the actual memory content. I've made with this code to Serial Output the TransmissionStatus on each attempt to now have 0x02 instead of the default 0xFF.

So everything is possible inside the deep core memory array where of course if no evident test or stress solves the control logic sub-system then finish.

Does anyone would have a schematics of the inside 24C02 showing the analog or internal parts to see if any analog test verification could be done on critical pins ?

[Tantratron]

Here's the way I'd go about it in your situation (with the equipment I have):
Start by comparing I/V curves of a good 24C02 and bad one, each pin relative to ground then Vcc using a scope with component tester. (Or Huntron tracker)

In case of differences without internal shorts or no differences at all, try playing on temperature while reading.
In case of an open pin, that could be due to a broken bonding also try playing with temperature and/or physically clamping the package while reading.

In case of a shorted I/O pin it's rather bad news, close to no chance of recovery but as it's dead anyway you could attempt to fuse the short ramping the current up into the short but keeping right polarity and maximum voltage.

Unfortunately I do not have a component tester as you describe but will first try to measure pins different impedance (good 24C02 versus the bad one) to see for a difference.

As for the technique to physically clamping the package I did not know of this so could you make a picture as an example how you do this ?

Regarding the temperature stress while reading, how would you recommend I do this in my kitchen or what Quick&Dirty method ?

By the way, no idea if we can find on internet the exact schematics of this 24C02 to help understand the pins-probing tests

Thanks, Albert

[mikeselectricstuff]

Voltage shouldn't be an issue for interfacing for reading -I2C is open drain, so just put the pullups to the Arduino supply.

[Tantratron]

Voltage shouldn't be an issue for interfacing for reading -I2C is open drain, so just put the pullups to the Arduino supply.

The arduino mega rev 3 board https://store.arduino.cc/arduino-mega-2560-rev3 has two pull ups 10K resistors (R1N and R1C)  for SDA and SCL lines

[Tantratron]

Here is a status and synthesis of these different days where I had lot of time to try different things at home due to Covid19 confinement.

The very good news, I've fully recovered the complete error-free content of the X24C02 eeprom via my arduino reader and voltage manipulations. See attached picture of my EEPROM reader with power supply trick then the java CRC test result of the EEPROM-1G content declared VALID.

For those interested to know the methodology of investigation, testing and more here are below the main steps.

First I did DMM diode test the reverse voltage of pin 5 (SDA) then pin 6 (SCL) versus the pin 4 (GND). Respective values were 0.82V and 0.95V then opposite polarities would give no value so I concluded the SDS and SCL input-output bus circuitry to be OK.

In the attached picture, you see the X24C02 to have 3 wires to program the 8 different A0 A1 A2 addressing of the I2C protocol where as a reminder, this U1052 chip uses 000 hardware address (0x50 in arduino) and the U1055 uses 001 (in arduino 0x51). The U1055 content of 256 octest were dumped without any problem as mentioned earlier this week, the issue was the U1052 failing any communication wether in the TDS540C or with arduino I2C read sketch.

I've modified my arduino EEPROM reader to now read the 8 different addressing modes then physically changed the 3 wires going to the EEPROM. So kind of cyber attack or ping to see 8 different HW mapping versus 8 different SW readings.

Reading address 0x50 or 0x51 or 0x52 or 0x54 or 0x56 would always indicate an I2C transmission status of 2 which is NACK (no response of EEPROM as a slave). However the 0x53 would provide status 04 (other error) then of high interest, the 0x55 or 0x57 would sometimes provide error code 4, sometimes provide an actual content then always freeze the arduino after reading few bytes. This was very time test consuming but I had time at home and once in a while I would read some local EEPROM values which seem to be always the same so there was hope.

I did try the higher voltage method initially suggested by SaabFAN but with no level shifter, namely I applied from 5V to 7V the power supply except I left 5V for SDA and SCL coming from the arduino. Nothing changed then early yesterday morning I thought to think out of the box, namely tried the other way around. As you can see on the picture, I've connected the EEPROM chip to Vin of the arduino instead of 5V pin and left the SDA and SCL connected to the arduino being 5V bus. In this special cas where the arduino receives energy via USB to my MacBook Air (not the input jack) the Vin happens to be 4.45V versus the other pins proving 5V modulated.

Do not ask me why electronically speaking where I've no idea of the internal schematics of X24C02 but it now works fine. This voltage method with asymmetry works, I was able to read completely the 256 calibrated data stored inside the X24C02 with the 8 different A0A1A2 addressing mode. I did revert to 5V power suppy and again impossible to dump any content.

After that I've concatenated the U1052 file with the U1055 to run the @flyte java parity checksum (see EEPROM_1G in attached test done on my Macintosh). So my TDS540C-1G has recovered its EEPROM complete factory calibration data and no need to run an calibration process where for the moment, I do not have the tools.

Voila, Albert

[ragge]

Interesting, thanks for information and congratulations!

[flyte]

Congrats @tantratron!    Very nice to see this productive feedback, so we can all recover from those to-desolder-or-not episodes in this thread! 

Indeed, I've also had some luck in the past with failing chips by stretching the limits, but you're often on your own and there is sometimes more luck to it than reason, depending on the failure mode which one mostly ignores. And half of the time you end up toasting it without luck. The usual things are trying to raise power levels, pulling up or down input and output levels, multiple one-shot reads pulling out the data, etc.

An interesting experience I recall from the past, which might help someone: one day I've recovered EEPROM data by reading every byte thousands of times. Data seemed purely random. But it wasn't, as I saw more "bit stability" when raising levels. Because I couldn't raise levels anymore without running the risk of blowing up the device, I took averages of every individual bit and put it to a definite "0" when its occurrence was over a certain frequency, statistically speaking. And then suddenly ta-da, the original data was back! It was a sort of quantum qubit-readout, lol! I had spent more than a week attempting to read it, but it was worth the time in gold as the cost of the data loss would have been so many times higher.

I'm sure this type of failure will reoccur with this particular EEPROM and thanks to your feedback someone will likely be able to get back cal data in the future using the same method.

Hint: if you post your dump, I can always check how far the actual values make sense. Because of the sloppy checksums used, there is a 1/65535 chance the checksum is valid by accident. Very unlikely, but I can verify if you want.

[Tantratron]

Hello @flyte,

Please find attached for your verification the ZIP file containing the EEPROM regenerated (combined, U1052 and U1055) along with previous screenshot showing some partial-fail reads before I though to locally decrease the voltage. Many many times the I2C controller in the arduino would freeze but as mentioned, sometimes I'd get some valid read on different part of the memory.

What made me decide to continue, I knew from your excellent floppy disk dumper-writer https://www.eevblog.com/forum/testgear/tektronix-tds500600700-nvram-floppy-dump-tool/ that the first eight bytes of U10152 should be ZERO and I saw this during very rare events in my attempts. I was about yesterday to develop a specific arduino code to read many times then merge or filter statistically the results to final byte decision (soft-decoding) but early in the morning I just thought trying with the voltage et voila.

On a side note, what motivated me to pursue was few weeks ago the cyber hacking international conference in Toulouse where Dr Kaveh Razahi exposed a HW attack to DRAM memory chip based on Rowhammer's fault model or read https://en.wikipedia.org/wiki/Row_hammer. Not saying we're in this situation but I was amazed and intrigued as a military digital radio consultant to see how far we can exploit or corrupt chipset.

[flyte]

On a side note, what motivated me to pursue was few weeks ago the cyber hacking international conference in Toulouse where Dr Kaveh Razahi exposed a HW attack to DRAM memory chip based on Rowhammer's fault model or read https://en.wikipedia.org/wiki/Row_hammer. Not saying we're in this situation but I was amazed and intrigued as a military digital radio consultant to see how far we can exploit or corrupt chipset.

Perhaps not within the scope of this thread, but hardware can be as vulnerable as software. And it's worse, as fixing may be impossible. The mindset is starting to change, but it has been overlooked for so many years as software is the usual suspect. And then we're not even talking about potential intentional hardware backdoors. Each time such a breach is announced, I find myself sitting on the edge my chair. The worst were probably the recent side-channel attacks on common Intel CPUs and indeed DRAM row hammering. Intel sort of fixed it, but we're not out of the woods yet (https://lviattack.eu/).

Regarding EEPROMs, in my experience it is nearly always side circuitry which fails or charges which deplete over time, but the data rarely completely vanishes. It's mostly locked inside to the point where levels are too faint for correct normal operation, or, if you're unlucky, even for recovery (using normal means).