Agilent E4420B Signal generator EEPROM problem

[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

[vladsol]

Both EEPROM's are AT28C256
IC107
IC106

[perieanuo]

as far as i remember, those ones are 'standard' algorythms between different suppliers, it was not the case of that at24c01 example i mentioned, so your eeprom programmer should normally do the trick

[perieanuo]

i just opened E4420B-U106-AT28C256E@PLCC32.BIN, seems legit(the first part looke like a version, that's fine, sometimes the firmware guys put some 'signature' at the end of the file too), except lot of that content is for me a little bit too repetitive
the 2'nd one bin file gave me the same impression, that the reading is corrupted, even at starting of the file
what programmer do you use?

[vladsol]

I don't think there is a problem with the programmer.
I use it quite often, and have never seen any problems.
Xgecu XGpro

[TheSteve]

It does sound like the eeprom data is corrupted. It may have been further corrupted during read/write. I believe you need a full calibration for it to be correct again.

[perieanuo]

sorry, i don't trust that programmer, but i don't want to start again programmers choice, i use batronix for delicate stuff like yours.
like @TheSteve said, you may be provoked corruption while verifying the eep

[vladsol]

Here, in addition to the EEPROM, there is also a copy of this (presumably) data itself in SRAM.
Initially (!), That is, BEFORE I removed the EEPROM chips, there was an error with the EEPROM COPY of TIMEBASE_DAC_FILE ... and RAM COPY OF TIMEBASE_DAC_FILE - there were no other errors.

From the description of error codes:

Data corrupt or stale; EEPROM copy of <filename>.
The EEPROM copy of a file is either corrupt or otherwise unusable. The
system automatically updates the non-volatile RAM copy of the EEPROM
copy using a default initialization.

Data corrupt or stale; RAM copy of <filename>.
The non-volatile RAM copy of a file is either corrupt or is out of date with
the EEPROM master copy (if one exists). The system automatically
re-initializes the file from EEPROM (if appropriate) or from a default
algorithm. A potential cause is a failing backup battery. (The battery was checked).

So we have two COPIES of files in SRAM and in EEPROM. But WHERE are the contents of these files copied from?

To justify this particular (Xgecu) programmer, I can say that I work with it very often. I flash NAND Flash chips (even large ones in a TSOP-48 package), different EEPROMs, and I NEVER had any problems. Perhaps you have other information on this subject, but I am sure of it.

[perieanuo]

i think one of eeps is calibration data, he gets some standard initial calibration data from flash, after calibrating the device he is updated with the calculated values from that calibration procedure. maybe the other one keeps the general settings, serial number etcaetera, tbo i don't know that particular device
one of them maybe can be tricked installed a virgin eep and calibrating, but the one keeping more vital information, should be written with correct data i guess, lookup for people that can provide you some working copies of flash+eeproms, that way you're covered if they doublecheck for example serial no in flash and eep

[vladsol]

Description for some of the memory chips:

[perieanuo]

so one is fw, second is cal data
can you try to upgrade fw and recalibrate after? this should eliminate your problem
imho, the fw eep content is the important one, the cal eep should be rewritten with standard calibration procedure
seems the bootloader is in one of the rom IC, so it should be simply to upgrade fw

[vladsol]

Unfortunately, I cannot update the firmware because the serial number and model of the device have been changed.
We need to find a way to flash the old serial number.
It is very strange that my dumps do not contain it (or it is not stored in text form).

[vladsol]

I re-read the contents of the U106 and U107 chips (after I wrote the original contents on them).
And I noticed some differences.

U106:



U107:

[vladsol]

Is it possible to set the serial number + model number via gpib?

[perieanuo]

i think it's only valid for getting sno, no setting it

[vladsol]

I've set the SN with SCPI command. But not the model number.

[perieanuo]

exactly, the pdf doesn't say write the sn, only read on that series
the read reports some valid sn, just my curiosity speaking here...?

[vladsol]

exactly, the pdf doesn't say write the sn, only read on that series
the read reports some valid sn, just my curiosity speaking here...?

SERV:PRODUCTION:CAL 165,0,38320193.15332;

38320193 is the sn. 15332 - country code (GB)

[perieanuo]

I re-read the contents of the U106 and U107 chips (after I wrote the original contents on them).
And I noticed some differences.

U106:



U107:

searching for that sno in your eep's content, i noticed u106 you posted before content stops at 3FFF you have print screen with 4bxx and for U107 also at address 100 i have totally different content on my screen, that means we can't assume their content is fine, maybe you choose by error wrong device when backup the eep's.
try at least to re-backup them as they are, then replace the cal eep with virgin one and see what happens, maybe it will be reconstructed by the firmware

[vladsol]

After installing the serial number via SCPI, I also tried to find it in the EEPROM - it is not there in clear text (text or hex).
I also noticed that after changing the serial number, the contents of the U107 did not change at all. Only the contents of U106 have changed.
As for the dumps, there is an error in the file names. The file named U106 is actually from U107 and vice versa.

In addition - there is no change in the behavior of the device, even if U107 is completely removed.
Well... Yes, i can try to erase U107 completely.

[vladsol]

I erased the contents of U107.
After starting the device and then turning it off, nothing was written to U107.
But if i write an old dump to it and change the serial number, then the hostid in the data on the U107 also changes.

Managed to get the serial number and model back. But hostid has changed.
SERV: PRODUCTION: CAL 165,10,2000.0906000000
= Equal to ESG-2000B
  as it was originally.
Do numbers after 0906 indicate installed software options?

[vladsol]

In general, I don't really need the software options that got lost (EDGE / CDMA / WCDMA) when hostid changed, and they can probably be left unactivated.

[vladsol]

Well... I guess, i need to calculate somehow the correct options, because now i have two additional errors:
+617,"Configuration Error;Installed option board not supported.  PARALLEL ATTEN"
+617,"Configuration Error;Illegal combination of installed option boards."

And the rest (in fact, there must be more of them, but only 30 are indicated):

-230,"Data corrupt or stale;RAM copy of PM_COUPLING_FILE"
-230,"Data corrupt or stale;EEPROM copy of PM_COUPLING_FILE"
-253,"Corrupt media;EEPROM PM_COUPLING_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_KV_FREQ_FILE"
-230,"Data corrupt or stale;EEPROM copy of FM_SENS_KV_FREQ_FILE"
-253,"Corrupt media;EEPROM FM_SENS_KV_FREQ_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_KV_PATH_FILE"
-230,"Data corrupt or stale;EEPROM copy of FM_SENS_KV_PATH_FILE"
-253,"Corrupt media;EEPROM FM_SENS_KV_PATH_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_MULT_FILE"
-230,"Data corrupt or stale;EEPROM copy of FM_SENS_MULT_FILE"
-253,"Corrupt media;EEPROM FM_SENS_MULT_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_ATTN_FILE"
-230,"Data corrupt or stale;EEPROM copy of FM_SENS_ATTN_FILE"
-253,"Corrupt media;EEPROM FM_SENS_ATTN_FILE"
-230,"Data corrupt or stale;RAM copy of TIMEBASE_DAC_FILE"
-231,"Data questionable;EEPROM copy of TIMEBASE_DAC_FILE"
-253,"Corrupt media;EEPROM TIMEBASE_DAC_FILE"
-230,"Data corrupt or stale;RAM copy of BAND_TABLE_FILE"
-230,"Data corrupt or stale;EEPROM copy of BAND_TABLE_FILE"
-253,"Corrupt media;EEPROM BAND_TABLE_FILE"
-230,"Data corrupt or stale;RAM copy of BAND_TABLE_BLANKING_FIL"
-230,"Data corrupt or stale;EEPROM copy of BAND_TABLE_BLANKING_FIL"
-253,"Corrupt media;EEPROM BAND_TABLE_BLANKING_FIL"
-230,"Data corrupt or stale;RAM copy of RF GAIN INDEX"
-230,"Data corrupt or stale;EEPROM copy of RF GAIN INDEX"
-253,"Corrupt media;EEPROM RF GAIN INDEX"


Has anyone managed to run AP/DP Motherboard Utility? Under Win10? XP? WIn98? 95? Tried all of them, but no luck.

[perieanuo]

the sno not being in clear text, it was expected, as it's somehow logical to scramble the data to avoid reverse engineering, cloning devices etcaetera.

regarding eep identify, i'm completely lost. you shared 2 32KB files, the doc points 2 eep (one 64KB, firmware and one 512B, calibration data), the other are referred as ROM, SRAM.
the doc doesn't correspond with what you found in the device, you said both eep's are AT28C256.U107 content (you say it's U106 in fact, the bin files are swapped) is almost half empty so maybe they put a bigger one for further upgrades or just because or production supply reasons.in this scenario, u106 is the eep containing cal data which can be easily replaced.

what i proposed maybe wasn't very clear, is to replace u107 eep with cal data with another one, not the same one cleared with your programmer (i don't trust that programmer and his 'empty' checks or his writing algo). with a new eep IC, try to rewrite the eep with recalibrating procedure of your device(after peeking into his manual, it's unclear how you can recalibrate this device, they mention "Press this softkey to perform a download of calibration data from the optional hardware into non-volatile memory", maybe you have some test rig they call "optional hardware"?).

btw, have you cleared sram? his content looks like it will be also restored by the device at first power-on. maybe try this first (in fact i suggest recalibrate>power off>clear sram>recalibrate). you haven't told us if you recalibrated

if you can't recalibrate, just clear sram, of course with the device disconnected from his power supply. apparently the device makes mirrors some parameters and data in sram and if this is corrupted (he checks sram content with eep, rom...) and this could throw out all sort of bizare messages like you specified in first post

hostid may be generated from sno, so it's ok to change if sno changes.

[perieanuo]

searching for cal procedure, found in page 35 of the manual some procedure applicable exactly to your case:
"If none of the previous suggestions resolves the problem, you can try the fail-safe recovery
sequence. This sequence should only be used as a last resort as it will reset the signal
generator but the process will destroy all user files (instrument state, sequence files, data
files), calibration data (unsaved I/Q calibrations, DCFM/DCΦM calibrations), and the
persistent state. Do not attempt to perform any other front panel or remote operations
during the fail-safe sequence."

of course, you should backup your data carefully before doing this, like software license no, cal data, all you can't recover after the procedure
the manual seems pretty well documented

[vladsol]

regarding eep identify, i'm completely lost. you shared 2 32KB files, the doc points 2 eep (one 64KB, firmware and one 512B, calibration data)

Yes, I'm confused about that too
From service manual:

U106 and U107 hold critical data including the serial number, option
configuration, and calibration information. You must transfer these devices to
the new CPU/motherboard for the signal generator to work[/b]
- BOTH U106 & U107

, the other are referred as ROM, SRAM.
the doc doesn't correspond with what you found in the device

The document i referred is "Agilent ESG A/B Security Features", applicable to E4420B too. Well... There is no direct mention of U107 and U106

it's unclear how you can recalibrate this device
...
maybe you have some test rig they call "optional hardware"?

Well... I don’t think it’s possible to calibrate without the service software and a bunch of measuring instruments connected via GPIB

Unfortunately, I don't have at hand the same device from which I could take a dump

have you cleared sram? his content looks like it will be also restored by the device at first power-on.

The EEPROM copy of a file is either corrupt or otherwise unusable. The
system automatically updates the non-volatile RAM copy of the EEPROM
copy using a default initialization. The actual EEPROM file is left as it is

So, with bad EEPROM (there is some sort of checksum?), i don't need to clear the battery-backed SRAM.

hostid may be generated from sno, so it's ok to change if sno changes.

Looks like not only from sno + model. Because i have set the serial number and model number to the values that were originally.


I wrote a simple script that I used to write a file to the EEPROM, read from the EEPROM and compare the checksum many (200) times.
0x00 pattern and random pattern was used (100 x each). No problems with U107



Why am I doing this? I don't have a replacement EEPROM yet

[vladsol]

if you can't recalibrate, just clear sram, of course with the device disconnected from his power supply.

Powering up with "Preset" + "Power on"? Yup. After that, all of the settings (including SN + Model number) Zeroed too (ESG-3000A + ASG-3000A).
Should this be the case?
I haven't done this before, so who knows, maybe the EEPROM was really damaged for a long time, and everything worked thanks to the data in the RAM.

[vladsol]

1. I have turned off the ESG without unplugging the power cable.
2. Power on the generator while holding down the Preset button. "Y" Pressed.
3. The ESG has rebooted. No serial number and wrong model. (ASG-3000, A00000000)
4. Turned off the ESG without turning off the power (without unplugging the power cable).
5. Turned on the ESG again. Native serial number and model returned. From EEPROM, i guess.

ERRORS LIST:
-230,"Data corrupt or stale;RAM copy of CONFIG_FILE"
-230,"Data corrupt or stale;RAM copy of PM_COUPLING_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_KV_FREQ_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_KV_PATH_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_MULT_FILE"
-230,"Data corrupt or stale;RAM copy of FM_SENS_ATTN_FILE"
-230,"Data corrupt or stale;RAM copy of TIMEBASE_DAC_FILE"
-231,"Data questionable;EEPROM copy of TIMEBASE_DAC_FILE"
-253,"Corrupt media;EEPROM TIMEBASE_DAC_FILE"
-230,"Data corrupt or stale;RAM copy of BAND_TABLE_FILE"
-230,"Data corrupt or stale;RAM copy of RF GAIN INDEX"
-230,"Data corrupt or stale;RAM copy of RF GAIN DATA"
-230,"Data corrupt or stale;RAM copy of ALC MOD INDEX"
-230,"Data corrupt or stale;RAM copy of ALC MOD DATA"
-230,"Data corrupt or stale;RAM copy of DET OFFSET FILE"
-230,"Data corrupt or stale;RAM copy of LOG OFFSET FILE"
-230,"Data corrupt or stale;RAM copy of POWER CAL GAIN"
-230,"Data corrupt or stale;RAM copy of POWER CAL OFFSET"
-230,"Data corrupt or stale;RAM copy of LEVEL METER OFFSET"
-230,"Data corrupt or stale;RAM copy of ALC REF GAIN INDEX"
-230,"Data corrupt or stale;RAM copy of ALC REF DAC GAIN"
-230,"Data corrupt or stale;RAM copy of ALC_REF_GAIN_2"
-230,"Data corrupt or stale;RAM copy of ATTEN INDEX FILE"
-230,"Data corrupt or stale;RAM copy of ATTEN CAL DATA"
-230,"Data corrupt or stale;RAM copy of ATTEN FLATNESS"
-230,"Data corrupt or stale;RAM copy of ALC MOD FLAT"
-230,"Data corrupt or stale;RAM copy of ALC MOD FLAT INDEX"
-230,"Data corrupt or stale;RAM copy of LNF ATTEN TRIP"
-230,"Data corrupt or stale;RAM copy of LNF ATTEN TRIP FREQ TAB"
-350,"Queue overflow"

6. Off/On again:
ERRORS LIST:
-230,"Data corrupt or stale;RAM copy of TIMEBASE_DAC_FILE"
-231,"Data questionable;EEPROM copy of TIMEBASE_DAC_FILE"
-253,"Corrupt media;EEPROM TIMEBASE_DAC_FILE"
-230,"Data corrupt or stale;RAM copy of TIMEBASE_DAC_FILE"
-231,"Data questionable;EEPROM copy of TIMEBASE_DAC_FILE"
-253,"Corrupt media;EEPROM TIMEBASE_DAC_FILE"

[vladsol]

-230,"Data corrupt or stale;RAM copy of TIMEBASE_DAC_FILE"
-231,"Data questionable;EEPROM copy of TIMEBASE_DAC_FILE"
-253,"Corrupt media;EEPROM TIMEBASE_DAC_FILE"
-230,"Data corrupt or stale;RAM copy of TIMEBASE_DAC_FILE"
-231,"Data questionable;EEPROM copy of TIMEBASE_DAC_FILE"
-253,"Corrupt media;EEPROM TIMEBASE_DAC_FILE"

The whole point is in the word "TIMEBASE"

In the instrument menu, I found the item "Reference Oscillator Adjustment"
After selecting it - without changing anything (127), I clicked "Store Ref Osc Setting".
Turned off, turned on - the "TIMEBASE_ *" errors disappeared.
That is, at the moment, there are no more errors when turning on.

So, if I understand correctly, the Internal Reference Oscillator Adjustment needs to be done. Of course, full calibration is better :-) But, since I use the generator for amateur purposes, it will be very expensive for me.

Of course, one would think that all these actions, flashing the memory chips, did not make sense ... But, nevertheless, it probably is not so This device is very old, according to the EEPROMs datasheet, the data retention period is 10 years. Perhaps I prevented damage to some more files in the EEPROM

[perieanuo]

that's good news, at least you found the problem.
if that reference oscillator parameter was affecting timing read/write of eeprom operation, that means without him at correct value, also sram was altered
i was expecting from their part to make eep read/write/program hardware-dependent only
regards, pierre

[vladsol]

I'm sure this osc is only for the RF section.

[vladsol]

What do you think? Will the Chinese GPSDO (OCXO?) be enough to calibrate the ESG internal reference? With 1E5 Opt.

[perieanuo]

if you notice deviation from normal device behaviour, you may do it, otherwise no. you may try using some frequency meter if you got one, see if the output is within specs or near specs
normally that osc should do, i tested like 5 years ago 2 chinese ones along with chinese cheap voltage references (the 10V ones, if i remember well...), they were accurate enough for 'hobby' calibrations or verification. take care at power supply, room temperature and little details like this (careful wiring...) if you decide to recal the ref frequency

[vladsol]

I was not happy for long :-)
A new problem has appeared - at any frequency and regardless of the amplitude - UNLEVEL error, when ALC is on. And.. No output, at all. E4400-60007  Atten is not clicking.
Well... there is also no output from output board itself (signal is wery weak, about -100dbm)... Checked at the attenuator input.
Output board was damaged? But how?

[perieanuo]

didn't studied the book, maybe alc have a linked parameter in those eep's and mirrored in sram somehow? like proportional (gain for alc )

[vladsol]

didn't studied the book, maybe alc have a linked parameter in those eep's and mirrored in sram somehow? like proportional (gain for alc )

That's strange. I've did the reset one more time, and unlevel error is gone.
But, indeed, it need's to be re-calibrated. The signal starts to be distorted earlier (+ 14dbm) than the UNLEVEL error appears (+ 20dbm)

[perieanuo]

you gotta take that thing to a priest, for exorcism
bad joke...