-
FIXED: Agilent E4418B repair: possibly require the FLASH EEPROM
Posted by analogRF on 13 Aug, 2018 03:51 -
I've got a dead E4418B power meter built around 2006. It's simply dead on power up, no display, no backlight, nothing on GPIB. The whole front panel is OK since I checked it on a E4418A I borrowed from work. So the problem is on the main board. All power supply lines are precise and solid, no issues there. I have done numerous checks on the power supply circuitry, the reset and battery backup circuits, LCD drive circuits, LCD backlight driving circuit, etc...all check out except that no PWM signal comes from the CPU to the LCD contrast and LCD backlight circuits.
Upon checking the CPU/memory side, there is activity with fairly good looking signal shapes around the CPU and all memory chips and the PAL. CPU is NOT in reset or halt or freeze either. It seems to me that the CPU is stuck at the very beginning of boot sequence (reading from FLASH into its own small on-chip RAM and perhaps performing basic tasks) before reading the whole firmware into the SRAM and running it. It's a hunch and i have no concrete proof for this
So my guess is that the FLASH memories are bad or corrupted (perhaps during a firmware upgrade though GPIB?!)
Now I have two questions: does anybody have (or can obtain) the binary file for the FLASH chips?
if I take the FLASH out and try to read it by my TL866 (AM29F040B is supported) is there a way I can definitely conclude that the FLASH is bad?
I have attached the schematics for the instrument.
-
I'll check my firmware stash once I get some time, but I do remember that newer sensor board DSP firmwares are not compatible with older main firmware. It might be worth trying to boot the unit without the sensor board installed.
I have downloaded firmware updates from the keysight website. I don't know if there is a bootloader or something that the download wouldn't contain which you would need.
Next weekend, I can try to pull the flash. I remember that one of the JLCC package adapter which comes with the TL866 leaves some pins floating, Vdd IIRC. I had to add a few bodge wires when reading a power supply ROM. -
I'll check my firmware stash once I get some time, but I do remember that newer sensor board DSP firmwares are not compatible with older main firmware. It might be worth trying to boot the unit without the sensor board installed.
I have downloaded firmware updates from the keysight website. I don't know if there is a bootloader or something that the download wouldn't contain which you would need.
Next weekend, I can try to pull the flash. I remember that one of the JLCC package adapter which comes with the TL866 leaves some pins floating, Vdd IIRC. I had to add a few bodge wires when reading a power supply ROM.
I am working on the bare bone system just the main board and front panel out of the case, so no power sensor board or even the comm board is attached which should be fine.
The FLASH chips are AM29F040BLL-70EC. They are TSOP32 package. I am planning to replace them with MX29F040CTI-70G from Digikey if I can get my hands on the binary files
if you could pull the flash or have the binary at hand, it would be AWESOME. I really appreciate your help.
-
I'd say to replace the sram.
-
I'd say to replace the sram.
That was my first thought and still I might end up trying that. However, I don't think the CPU is reaching a point that it needs to write the firmware into the SRAM yet. It is stopped at very early stage. If you look at the video by Shahriar (Signal Path) on repairing a E4418B, his unit had dead RAM chips but the CPU was turning on the LCD and putting out a message, too...Besides, there are 4 SRAM chips so I try to avoid changing them as much as possible
-
....I have downloaded firmware updates from the keysight website. I don't know if there is a bootloader or something that the download wouldn't contain which you would need....
I thought about using the firmware file from keysight, too, but apart from the issue of probably not having the full data of the flash in there, the other problem is that I need two files for two flashes. So that firmware file must be split somehow... -
TiN on xdevs has small snake script to split binary, you have to know address where to split.
-
TiN on xdevs has small snake script to split binary, you have to know address where to split.
but who knows the address? besides, is it really possible to just split the downloaded firmware file and put it in blank flash chips? there is possibly a boot loader or something that is not in the downloaded file. The two flashes are 512KB each and the firmware file is about 844KB
-
I'll check my firmware stash once I get some time, but I do remember that newer sensor board DSP firmwares are not compatible with older main firmware. It might be worth trying to boot the unit without the sensor board installed.
if you could pull the flash or have the binary at hand, it would be AWESOME. I really appreciate your help.
I fear that I spoke too soon. I didn't remember that the ROM was soldered onto the board (and I would rather not desolder it). When doing an update, it downloads the ROM image to the computer (for backup purposes). Perhaps that would be the full image... I'm not sure. I have an EPM-441A which might have a different bootloader... I'm not sure.
You could also try doing a firmware load over the serial port? -
the serial port is also dead. The cpu is stuck at the very first step of booting so nothing in the system has started yet and that's why I believe the firmware is corrupted or the flash chips are bad.
if you can dump your flash through the serial bus or gpib it can still help. it might include the whole content of the chips
...oh, but again you will get one file and I need two bin files for the two chips
-
Being the flash chips are soldered in it is unlikely someone will be desoldering them to dump them for you - unless someone has a purely parts board.
At this point if you think it is the flash then why not desolder the two in your unit, read them and post the files.
Keysight has a full archive of the various versions so we can take a look and see what/if it matches a downloaded version. Splitting/combining the files shouldn't be a problem with TiN's python script. Maybe we'll find some corrupted bytes or an entire erased sector. It looks like the cal data is also in the flash chips, so it would be ideal to read yours no matter what. -
....
At this point if you think it is the flash then why not desolder the two in your unit, read them and post the files.
Keysight has a full archive of the various versions so we can take a look and see what/if it matches a downloaded version. Splitting/combining the files shouldn't be a problem with TiN's python script. Maybe we'll find some corrupted bytes or an entire erased sector. It looks like the cal data is also in the flash chips, so it would be ideal to read yours no matter what.
yes, that's the best idea, I think, since I have no other clue as to what might be wrong with the unit. I am assuming the PAL and CPU are OK, then my best guess is the flash chips first and maybe the SRAMs after that.
I have just found out that I do not have proper adapter for the wide TSOP32 packages in order to read them by TL866 programmer (I thought I had it in the pile of adapters that I have) so I have ordered the adapter and waiting for it. But, yes my next step is definitely to take the FLASHes out
However, again the question is: does the downloaded firmware contain the entire content of the FLASH chips? -
Upon checking the CPU/memory side, there is activity with fairly good looking signal shapes around the CPU and all memory chips and the PAL. CPU is NOT in reset or halt or freeze either. It seems to me that the CPU is stuck at the very beginning of boot sequence (reading from FLASH into its own small on-chip RAM and perhaps performing basic tasks) before reading the whole firmware into the SRAM and running it. It's a hunch and i have no concrete proof for this
So my guess is that the FLASH memories are bad or corrupted (perhaps during a firmware upgrade though GPIB?!)
Before taking out the flash chips did you check if they are addressed at all (CE,OE)? It could be 'just' an address decoder gone bad. -
Before taking out the flash chips did you check if they are addressed at all (CE,OE)? It could be 'just' an address decoder gone bad.
yes. they are addressed. in fact it seems to me that the cpu is stuck at trying to read from them.
The CE of the flash chips is directly connected to CSBOOT pin on the CPU and it is constantly LOW (active) Nothing else is connected to this line at all.
The OE of all memories (ram and flash) comes from the PAL and there is activity on it. The WE of all memories comes directly from the RW pin of the CPU and it is active, too. This line also goes to the PAL as well. -
As a long shot, I also contacted Keysight and they just came back to me saying neither the binary files nor the programmed chips (FLASH ROM) are available anymore.
-
Did you ask on the yahoo HP-Agilent group? Someone there might have a copy of the firmware (I went and took a quick look but didn't see anything more than what is on the Keysight website).
TonyG -
yes, I have posted the problem on yahoo HP group. No help...those guys are busy with moving to groups.io and lots of complaining about receiving too many messages, etc...nothing much is going on there right now...
-
Did you ask on the yahoo HP-Agilent group? Someone there might have a copy of the firmware (I went and took a quick look but didn't see anything more than what is on the Keysight website).
TonyG
by the way, I always liked your videos but you have not produced anything in a long time...I hope we see something soon ! -
Thanks - Appreciate the kind words.
Between vacation, work and my wife's mother passing away I just haven't had time to get to the bench - We have all that behind us now so I'm hoping to get Part 2 of the drive repair done soon.
TonyG -
yes, I have posted the problem on yahoo HP group. No help...those guys are busy with moving to groups.io and lots of complaining about receiving too many messages, etc...nothing much is going on there right now...
The move to Groups has been discussed for some time, I'm hoping that the forum will get there shortly and we can have a better experience.
I see that there was a response this morning with more detail on debugging the issue. For those interested the thread is:
https://groups.yahoo.com/neo/groups/hp_agilent_equipment/conversations/topics/90969
TonyG -
Between vacation, work and my wife's mother passing away I just haven't had time to get to the bench - We have all that behind us now so I'm hoping to get Part 2 of the drive repair done soon.
sorry to hear that
but absolutely looking forward to the upcoming videos. More HP gear please!
-
I see that there was a response this morning with more detail on debugging the issue. For those interested the thread is:
https://groups.yahoo.com/neo/groups/hp_agilent_equipment/conversations/topics/90969
yes, I saw that. I have to see if it can get me anywhere. I don't have a logic analyzer, so what he is suggesting is difficult to do with oscilloscope if not impossible. And yet no way how to get the binaries for flash chips
-
It's been a while since the last post but I thought to give an update on the E4418B repair. The unit is fixed (almost) and here is the story
I went back to my original troubleshooting notes and noticed that what was stuck on my mind, and I wrote in the posts here, was actually not correct. The CSBOOT pin of the CPU which is the CE of FLASH chips is indeed active but the CE of U11,U12 SRAMs is stuck at LOW (disable) and CE of U39,U40 is stuck at HIGH (enabled). I checked again and confirmed my notes were correct. That indicated to me that the CPU is trying to read from/write into the boot SRAMs U39,U40
The SRAMs were cheap, so I replaced U39,U40 and, lo and behold
the unit turned on and passed all self tests 
I think what threw me off the right path was the behavior of the E4418A repaired by Shahriar on his youtube video. In his case the same two SRAMs were bad but the display was turning on and there was a message from CPU so I was expecting that my unit is stuck at an earlier stage. However, this is E4418B with a different firmware and I guess the behavior is different.
Now the problem is that the keypad is also bad, the REF LED does not turn on even though the voltage is correct and the power on button does not work either. I could not repair the keypad so I ordered one from china. Hopefully that will be the last issue with the unit.
TheSteve had told me in the beginning to change the SRAM and I did't listen
-
Outstanding - update us with the rest when you get the bits.
TonyG -
just a quick update on the final state of the E4418B. I received the key pad from china ($46 incl shipping with UBI which is fairly fast). Photo is attached here. Replaced it and the unit works like a charm now. Slight calibration of the ref. osc. was needed which I crudely did with the help of another E4418A and E4412A power sensor I borrowed again from work. The actual cal process is more complex and requires HP 432A with thermistor which i don't have. but it all works ok now
One thing I noticed and I hope someone could check it, is that if you go to Systems and then to Version, it shows up as E4418A.