Agilent 34461A corrupted flash

[dc101]

I have a Agilent 34461a that's well out of warranty and no longer boots. Thanks to previous threads on this forum I was able to determine it's a result of corrupt/dead flash, although I can't 100% rule out a more serious issue. I suspect this may have resulted from leaving it unplugged for some amount of time. I emailed Keysight and asked them for a copy of the pboot.bin image and nk.bin, but I'm not very optimistic they will send me the files.

Does anyone here have a copy of pboot.bin and nk.bin? Or is anyone who has a 34461a willing to try and dump these files? My 34461a is running U-Boot 2010.03 (Oct 09 2012 - 12:48:30)Agilent P510. I was able to flash nk.bin that I grabbed off the USB thumbdrive for a front panel update, but without pboot.bin there is no kernel to boot nk.bin, and I'm not 100% the nk.bin I flashed is in the correct format.

Boot log:

Code: [Select]

U-Boot 2010.03 (Oct 09 2012 - 12:48:30)Agilent P510

CPU:   SPEAr320
DRAM:  128 MiB
Unknown id: 0xffffff. Using ST_M23P40
Flash: 64 KiB
NAND:  INTERNAL ECC 128 MiB
In:    serial
Out:   serial
Err:   serial
SerNum:MY99999999
Chip:  AA Board Rev: 4
init  RTC: 2021-03-22 21:08:23.75
Net:   No ethernet found.
splash RTC: 2021-03-22 21:08:24.78
Press space to stop autoboot:  0

NAND read: device 0 offset 0x320000, size 0x10000
 65536 bytes read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
p510>

Sure enough if I list the flash images, pboot is definitely gone:

Code: [Select]

*********************   NOR Flash Images   *********************


*********************   NAND Flash Images   *********************
Image at  offset 00000000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00020000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00040000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00060000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00100000:
   Image Name:   UBOOT
   Created:      2012-10-09  18:59:15 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    237084 Bytes = 231.5 KiB
   Load Address: 03f00000
   Entry Point:  03f00000
   Verifying Checksum ... OK
p510>

Cheers
-Tim

[dc101]

On a whim I grabbed pboot from my 53220a, but unfortunately the units are not as similar as I thought. I was hoping it would at least boot, but it stops shortly after loading.

Keysight has already informed me that I need to send the unit in for repair because there are "no user repair actions available."   

Code: [Select]

U-Boot 2010.03 (Oct 09 2012 - 12:48:30)Agilent P510

CPU:   SPEAr320
DRAM:  128 MiB
Unknown id: 0xffffff. Using ST_M23P40
Flash: 64 KiB
NAND:  INTERNAL ECC 128 MiB
In:    serial
Out:   serial
Err:   serial
SerNum:MY99999999
Chip:  AA Board Rev: 4
init  RTC: 2021-03-22 23:06:53.27
Net:   No ethernet found.
splash RTC: 2021-03-22 23:06:54.31
Press space to stop autoboot:  0

NAND read: device 0 offset 0x320000, size 0x10000
 65536 bytes read: OK
## Booting kernel from Legacy Image at 00600000 ...
   Image Name:   PBOOT
   Created:      2009-10-22  11:56:02 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    37189 Bytes = 36.3 KiB
   Load Address: 00000000
   Entry Point:  00000000
   Uncompressing Kernel Image ... OK

Starting kernel ...


Debug serial initialized ........OK


[perieanuo]

Unknown id: 0xffffff. Using ST_M23P40
imho tah means the memory chip is not responding at all
haven't yes seen chips with good memory space and not responding to ID interogation, but who knows, maybe others have seen this
corrupted or defective flash for me means remove memory/test in external programmer/replace or reprogram
i'd guess, the flash is not 'corrupted', is not responding at all
if you cand find the .hex, remove and replace with new programmed flash chip, or maybe your agilent have some sort of firmware update procedure if the flash is empty, i don't know that agilent model

[dc101]

I've been wondering this exact thing, is the flash corrupt, did the flash die, is the DDR bad?

I have a BGA63 socket in the mail that I ordered for a different project, so I could buy a new flash chip and reprogram it, but like you said I need to find the hex files to program it with. I believe I can use the nk.bin file from the firmware update, but pboot.bin is proving impossible to find. I may have to eat the cost of buying a new front panel, I believe it's around $US 250.00.

[perieanuo]

sometimes a good empty flash can do it, have you tried just replacing that flash? at least, you will see the message changing and maybe update proposed.
(I suspect from "Using ST_M23P40" you can try this type of flash or somethin,g with same size or bigger and same reading/writing algo, if you got one in your spare parts)
plus, it's a simple so8
 case, so changing it it's really simple even with some soldering station

[Dr. Frank]

34465A/470A may be similar / identical, as all DMMs share same Firmware update files.
Where and how can one extract this Flash Boot Loader ?

Frank

[dc101]

Frank - That might actually work! I found some photos of the 34465a on the forum from radioFlash and the ARM processors are the same.

It's not a hard process, but there are a few steps to it. It does involve removing the instrument cover which may void the warranty? So understandable if you'd prefer not to. Once the cover is off you'll need to connect to the serial port on the back of the front panel that mikeselectricstuff identified in the original 34461a thread. On the 53220a and 34461a the serial port is real 12V levels, but probably worth double checking on the 34465a. After that there are a few u-boot commands you will need to run. There is no way to download the binary straight from flash that I know of, so here's what I did when I downloaded pboot from my 53220a: List the images loaded in flash, load pboot from the given flash address into ram, print the ram contents, copy and paste the ram output into a text editor to format the text properly (remove addresses, spaces, newlines etc...) then copy and paste the properly formatted ascii hex into HxD to save as binary.

One thing I would highly recommend is running the u-boot protect command to disable writing to flash, this will prevent you from accidentally overwriting/erasing sections of your flash. It was an errant copy and paste in putty that erased my pboot Previously it was just nk.bin that was corrupt in flash.

I would be very grateful if you would be willing to attempt to download pboot from your meter; I am willing to pay you for your troubles. I will connect to my 53220a and document the exact u-boot commands required and the TX/RX/GND pins of the serial port, so you have a better understanding of the exact process.

Thanks again
-Tim

[Dr. Frank]

Frank - That might actually work! I found some photos of the 34465a on the forum from radioFlash and the ARM processors are the same.

It's not a hard process, but there are a few steps to it. It does involve removing the instrument cover which may void the warranty? So understandable if you'd prefer not to. Once the cover is off you'll need to connect to the serial port on the back of the front panel that mikeselectricstuff identified in the original 34461a thread. On the 53220a and 34461a the serial port is real 12V levels, but probably worth double checking on the 34465a. After that there are a few u-boot commands you will need to run. There is no way to download the binary straight from flash that I know of, so here's what I did when I downloaded pboot from my 53220a: List the images loaded in flash, load pboot from the given flash address into ram, print the ram contents, copy and paste the ram output into a text editor to format the text properly (remove addresses, spaces, newlines etc...) then copy and paste the properly formatted ascii hex into HxD to save as binary.

One thing I would highly recommend is running the u-boot protect command to disable writing to flash, this will prevent you from accidentally overwriting/erasing sections of your flash. It was an errant copy and paste in putty that erased my pboot Previously it was just nk.bin that was corrupt in flash.

I would be very grateful if you would be willing to attempt to download pboot from your meter; I am willing to pay you for your troubles. I will connect to my 53220a and document the exact u-boot commands required and the TX/RX/GND pins of the serial port, so you have a better understanding of the exact process.

Thanks again
-Tim

Tim,
that sounds feasible.
The replacement of the current fuses requires to remove the cover.. so there is not "guarantee void"
I have done that many times already because I e.g. experimented with the LM399 vs LTZ1000 reference.

If you provide details about this internal interface, and the necessary serial port monitor programs, I'll try it.

Frank

[dc101]

Awesome, I have the steps written down, so hopefully it is fairly straightforward. If you're on Windows I would suggest using MobaXterm (https://mobaxterm.mobatek.net/download.html) and for Linux my goto is Minicom which can be installed with apt-get install minicom.
 
Step 1 - Make physical connection to serial port on back of display (see attached picture for pinout)
Step 2 - Open terminal program, and set the serial connection as follows: 115200 baud, no flow control, data bits 8, stop bits 1, parity bits none
   For MobaXterm, you click on the session icon in the upper left and select Serial from the popup. The baud is set on the main screen and other settings are under Advanced Serial Settings.
Step 3 - Power on unit and press space bar in MobaXterm to abort autoboot process. You should see a prompt that says "p510>"
Step 4 - Type "protect on all" and press enter. This will enable flash write protection.
Step 5 - Type "imls" you will see several sections under NAND Flash Images (removed here for brevity). PBOOT should be the last entry and we need to know the image offset for the next step. Your PBOOT should look a little different from the one below, as this is the one from my 53220a.

Code: [Select]

*********************   NOR Flash Images   *********************


*********************   NAND Flash Images   *********************
.....
Image at  offset 00320000:
   Image Name:   PBOOT
   Created:      2009-10-22  11:56:02 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    37189 Bytes = 36.3 KiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
p510>In my case PBOOT is at 0x320000 in flash. I'm not sure if it's the same across the product range.
Step 6 - Type "nand read 0x600000 0x320000 0x10000" and press enter. Change 0x320000 to the correct address of PBOOT if it is different. This command will load PBOOT from flash into RAM at address 0x600000. This is the same command the device uses when it normally boots except we're only going to print the ram contents and not boot from them.
Step 7 - Type "md.b 0x600000 0x10000" and press enter. This is the memory display command and will display 0x10000 bytes starting at address 0x600000.
Step 8 - The last step, simply right click on the MobaXterm screen and select Copy All. Paste the contents in your favorite text editor and that's in. I can take care of formatting the data and converting it into a binary.

Thanks again! Let me know if you run into any issues. Fingers crossed this works!

-Tim

[Dr. Frank]

My 34465A looks identical; serial interface identified; obviously the boot loader FW should be the same vintage from ~ 2010.

Concerning the command "protect on all", is this a permanent lock, which I have to reset after the operation?

I fear, otherwise, I would not be able to do a FW update any more.

Frank

[dc101]

I believe your correct. I was actually just reading over some u-boot web pages again this morning and had the same thought. http://www.denx.de/wiki/view/DULG/UBootCmdGroupInfo

It might be a good idea to run protect off all after you finish, for exactly the reason you mentioned. Or alternatively you do not have to run the protect command in the beginning.

At the time I was using Putty as my terminal program and it has a rather annoying "feature" where anything that is highlighted by the mouse is automatically copied to the clipboard and just right clicking the mouse button will paste whatever is currently in the clipboard. This is what got me in trouble when I was trying to restore nk.bin. This is also why I recommended MobaXterm, at least there you have to explicitly select copy and paste.

[Dr. Frank]

OK, thanks, all went fine, appended dump to my recent post.
Have fun, and please report back if this could fix your 34461A!
Frank

[dc101]

Well that definitely did the trick, it's able to boot the windows ce kernel (pboot)! Now I need to see about reflashing nk.bin to correct places and see if it will boot up fully, or if there are in fact other issues with my meter. Thanks again!

[dc101]

Well the journey continues. PBOOT is working, however it seems that the version of nk.bin that comes with the official firmware update is not in the correct format be loaded directly from ram, or stored in flash and loaded into ram. The attached screenshot shows what the meter looks like after trying to put from nk.bin.

I've read some forum posts regarding Keysight scopes having success booting from the Windows CE platform builder, so I'm attempting to try that now. I'm in the process of updating my Windows XP CE development machine, and will report back with any news.

Cheers
-Tim

[ddcc]

I was curious, so I took a quick look. The NK.bin file is stored in the compressed XPRS format, so you could try decompressing it first. See https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1035605/#msg1035605 for a direct link to bincompress.exe, or you can probably find it somewhere in the Windows CE SDK.

[dc101]

Thank you! I had looked at the bk.bin for the 53220a, and compared it to the nand flash on mine and noticed there was quite a difference, this certainly explains things. I'll definitely look into that. I just finished installing VS 2005 and CE 6.0 on an XP VM so I'll take a look in there. I messed around with WinCE 6.0 when the FLIR C3 was released a few years back, but haven't touched it since then, so I've forgetting almost everything.

[dc101]

This makes SSOOOO much more sense now. I've been scratching my head all day trying to figure out why it seemed so easy when I loaded the FLIR C3 nk.bin in platform builder, but it just wasn't working with the 34461a firmware until after I decompressed it with the file you mentioned. Sure enough, it was in one of the WinCE directories. Once I decompressed it, I just added it to a project in WinCE like any other file and it opened right up.

I'm uploading it to my meter now via ymodem, so I've got some time to kill before it finished uploading. For whatever reason I never got u-boot to recognize any USB storage devices.

[dc101]

Sooo.... I'm going to call this a win. A quick test of a dead 3V coin cell battery and shorting the probes.
" alt="" class="bbc_img" />

It definitely works, but the serial number and model number are gone and I'm not exactly sure how to restore them.

Also the firmware update fails.


I'll have to read the DSO2000/3000 scope thread as I'm wondering if this issue has come up before. The service manual for the meter warns against swapping the front panel with another unit, so I'm assuming the serial/model number is stored some place in the ARM processor or in the NAND flash.

This correlates to some of the output on saw on the serial port while the unit was booting:

Code: [Select]

Inguard Bootup Complete -- OK
InguardBootup Buffered Test Signal detected
serialNumberW = 0000000000
rtnCode = 0

serialNumberW = 0000000000
rtnCode = 0

serialNumberW = 0000000000
rtnCode = 0

serialNumberW = 0000000000
rtnCode = 0

serialNumberW = 0000000000
rtnCode = 0

[TheSteve]

The master model/serial # is in the front panel. It is also stored on the mainboard. If you were to buy a new front panel it would be initialized such that when it was first connected it would read the model/serial from your mainboard. It would then be stored in the front panel and can no longer be changed.
There are also SCPI commands to set them, but it is unlikely they will work.

Still worth a shot:

diag:ofinit "SERIAL", "MODEL"

[dc101]

I did some more digging and found an interesting u-boot command factory.

Code: [Select]

p510> help factory
factory - factory - program factory data into NAND memory


Usage:
factory <address>
    - the first 2K of RAM <address> will be written to NAND at the appropriate block
p510>Interestingly, it only takes one argument, the ram address to read from. This means that the NAND address must be hard coded in the function. Sure enough, a few minutes of IDA and we find that the hardcoded NAND address is 0x80000. We also find something that's probably a little more interesting. An undocumented argument. Looking at the pseudo code in IDA, it first checks the number if arguments passed to factory. If that number is equal to 2, it checks to see if the word list is contained in the argument. Following the code, you'll see that passing list will print the factory data stored in NAND. If list is not found it assumes you passed an address and will write the first 2K of the specified address to the NAND address 0x80000

Code: [Select]

p510> factory list

Manufacturing Data
        MAC: XX-XX-XX-XX-XX-XX
        GUID: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXX
        SN: MY99999999
p510>This should help us understand the exact format the data needs to be in, and allow anyone to reprogram their serial number. Still a little fuzzy on the model number though, unless it is somehow related to the GUID?

[Dr. Frank]

Hi Tim,
the model is also contained in the serial number, I assume.
MY547xxxxx is for 34470As,  MY545xxxxx for the 34465A, please cheek the Serial Number of your 34461A.
Therefore there might be no distinct configuration (model #) parameter.
The hardware platform for all 4 instruments seems to be identical. the 460/461 have the same Mainboard, as well as the 465/470 PCBs are identical, apart from the reference.
The difference between the lower grade instruments vs. the higher grade ones seems to be a different / lesser assembly, to tailor the different features in hardware.
See 'New 34470A review' thread, where we analyzed all PCBs.

The differentiation in features and also the options like Digitizing and Memory is probably set up by firmware switches / keys only.
I assume that KS implemented a strong encryption of all these objects, to prohibit easy modification.
The serial number as well will be encrypted I assume, and as The Steve already claimed, stored in different places.

Anyhow I'm very interested, how to enable the 7 1/2  digit display on my 465A, as I already found out, how to upgrade the reference to the LTZ1000A .
Frank

[dc101]

Hey Frank,

Thanks, I'll check out that thread you mentioned. I'm thinking now that factory u-boot command might be some legacy code that is no longer used as the serial number showed in the help -> about menu, even before setting it with the factory command. My serial number starts with MY532, which matches the factory sticker and what is displayed on the screen.

I tried the SCPI command that The Steve mentioned, but as he guessed, it did not work. When I first uploaded new firmware and booted up the meter I saw something about detecting a new processor and taking a few minutes to update something. I wonder if the SCPI command would work when that screen is displayed?

The unfortunate part is I can't seem to be able to do a firmware update from USB or ethernet, due to the missing model number, which is preventing me from being able to get the firmware flashed to NAND. Even after uncompressing nk.bin, it still only loads from RAM. I wrote it to NAND, rebooted and read it back into to RAM and it loaded fine, so I don't think it's a NAND issue. Yet if I write nk.bin to NAND and verify the images with the CE bootloader, the NAND image comes back as invalid, while the RAM image is valid.

It's possible the issue might still be with pboot. I noticed after flashing the version from your meter, that the default NAND addresses are different from the 34461A. The RAM image was the same however at 0x84000000

Code: [Select]

34365A
Image addresses. (0xdxxxxxxx for NAND, 0x8xxxxxxx for RAM)
        1 (0xd0400000)
        2 (0xd1700000)


Code: [Select]

34461A
nimages=2
image1=0xd0620000
image2=0xd2120000


[Dr. Frank]

I made some errata to my former post, and here's the correct link to the discussion of the 461/465/470:
https://www.eevblog.com/forum/testgear/keysight_s-new-34465a-(6-5-digit)-and-34470a-(7-5-digit)-bench-multimeters/150/

some pages earlier or later, we already discussed possible feature switches, afair.

If I remember correctly, during the normal boot process, the serial number is displayed on the serial monitor.. and I did not blank my serial number inside the pboot dump file.


Frank

[dc101]

So looks like the DIAG:OFINIT SCPI command worked after all. It didn't work immediately after getting the new cpu alert, but after repeatedly sending the command I noticed I stopped getting errors on the scoped. I thought maybe I just broke SCPI, after a reboot now I see it actually has a model number. For another test I ran *IDN? and this time it actually worked. The first time I tried this after flashing new firmware, my scope crashed and reset.

[TheSteve]

Very nice that it worked! I have a different device I'd like to reset the model and serial # on. Any thoughts on exactly what was erased to lose the model/serial #? If the model/serial # are set the command certainly doesn't work.