Electronics > Repair

Agilent E4420B Signal generator EEPROM problem

(1/9) > >>

vladsol:
I have an Agilent E4420B signal generator.

In working condition, but on startup, shows an error: Data corrupt or stale; EEPROM copy of <filename>

I decided to check the EEPROM chips for errors (read-write) in the programmer. It turned out that there were no problems with them. But after that there were even more errors (-250 and -253).
The battery was replaced.
But, unfortunately, nothing changed.

vladsol:
After that (De-solderingthe EEPROM's U106 & U107 and soldering them back), the serial number of the device disappeared (AA000000000).
I can confirm that contents of these IC's is not changed since de-soldering.

Aheld:
Hi,
Might it be that the eeprom had some kind of internal structure, which is destroid?
Do you still have the content of this eeprom to mirror it to new eeprom device?

I know from other devices that eeproms become „stupid“ if the supply voltage is on crirical value. Then sometimes devices read wrong information or destroy content while writing. I have comparable generator and since weeks, I have „changing elkos“ on my to do list, because of strange behaviour.

Maybe this could be also a good idea before fixing eeprom issues?

vladsol:
After I unsoldered the EEPROMs, I dumped their contents.
For convenience, I soldered the sockets for the EEPROM chips.

EEPROM chips go through erasing - writing - reading without errors. Recovered their contents from a dump - but that didn't help. All voltages on the CPU board are normal.
The waveforms on the EEPROM address pins and data pins are normal...And i can conclude that reading is happening from both chips.

However, I cannot find the line that matches the serial number of the device in the IC106 & IC107 dump files
Is the serial number of the device actually stored in one of them?

perieanuo:
hi,
what eep's are in there?
cause one time with a simple at24c01c (they have different algo, like xilinx ones, if you compare them with st and other mainline ones) me and a more experienced electronics engineer with lot of experience, took it in the face: the eep programmer read/verified OK the eep, but in fact, the eep programmer used the 'mainline' algorithm so the read/write/verify was pure garbage, but the garbage 'checked out'.
we finally nailed it out (cause the machine controlled by that eep told us we are stupid, so back to bench and correctly programm the eep)
so don't exclude a simple mistake on your eep parts on verifying side wiyh your eep programmer.
put on the table what eep/ the data you extracted and the programmer you used, maybe someone see something
in your case, the 'machine' tells you something you don't catch

Navigation

[0] Message Index

[#] Next page