Electronics > Repair
Agilent 34461A corrupted flash
<< < (6/41) > >>
dc101:
It may have been when I probably erased more of the NAND flash than I intended to? When I was first starting my attempt at reflashing nk.bin, I didn't specify a block_size, so I'm pretty sure that I erased everything after whatever the starting address was. Probably worth looking into a little more, since I still have to upload an nk.bin image to RAM after power-on/reboot to get it to fully boot.

That being said, I still don't really know what happened to my meter to cause it be in it's current state. For months it had trouble booting, but usually unplugging it for a few minutes plugging in back in and then turning it on would work. Unfortunately I didn't think the problem was serious, and I never thought to look at the serial console at the time. Eventually it got to the point where it didn't matter what I did, I'd just get the Keysight splashscreen and the serial console indicated all 3 images were invalid. Perhaps whatever caused this, also caused it to lose the model number as well?

-Tim
TheSteve:
I have a Keysight 33622A that boots but won't enable any output as the FPGA authentication fails. All other self tests pass. There is a Dallas 1 wire secure IC with the FPGA that performs a secure handshake with the main processor, if it fails the meter won't work. It is tied to the model/serial # I am sure and is there to prevent someone else from ripping off the FPGA code(only reason I can think of). It seems my meter is a prototype and I'm wondering if the secure IC was never configured/programmed and worked fine with development firmware. Then someone updated to normal production firmware and it no longer operates. At that point they gave up and sold it, now I own it. The model # and serial # are correct. They are both also stored on the main board in an eeprom but if you blank that it will just silently reprogram it at boot from the front panel CPU processor. The ofinit command doesn't work because it is already programmed. I am wondering though if I was to erase the model/serial # like you did if it would also generate whatever is needed to work with the secure IC again when running the ofinit command. Obviously I don't want to erase anymore then needed.

The address location change in your 34461A is also interesting, it seems like it thought the dataspace was in use and shifted the address down and then wrote pboot in a new location. You may have slightly less NAND space then you had originally, not likely an issue though.

edit - if you perform a "factory list" Do you see your serial # listed? I tried it with my 33622A and have a valid MAC and GUID but there is no serial #.
dc101:
When I first tried factory list it showed the same serial number as u-boot, MY99999999, but I can't be sure that's not because of current issues. I'll have to try that with my 53220A and see what it returns. Perhaps Frank can try on his scope as well? I'm not sure if that's legacy code or not.

After first reboot, it appeared the DIAG:OFINIT was not permanent as my model number was lost. But after additional tests, the model number seems to remain in memory even after unplugging the meter for several minutes. One interesting thing is that even after running the DIAG:OFINIT command, I was still unable perform a USB firmware update and received the same "Incorrect firmware loaded for this model number." unfortunately after trying the firmware update again I get a warning saying the firmware on the USB is the same or older and after pressing yes to continue, the unit simply freezes and the front panel stops responding. The web interface still seems to work though.

My current boot process is to abort the autoboot, load the NAND image2 into RAM, and issue the normal boot command.  By default this pboot boots from the RAM image. It's still a pain, but better than uploading nk.bin using ymodem after every reboot.

Out of curiosity, I ran the DIAG:OFINIT command with my serial number but changed the model number and got a "-310 System error" so there is definitely some logic checking happening in the meter.

Regarding the NAND address shifting, that seems to be related to using Frank's pboot since we have different meters. The problem is everytime I try a firmware update, the u-boot values seem to reset to their original settings. The FBGA codes on the NAND are different, although I haven't looked up the one for the 34465A, so I don't know the exact differences.

-Tim
TheSteve:
I have a 34461A - maybe I should dump the pboot from it.
dc101:
If you could, that would be super helpful. I'd be very curious to see what the default NAND locations are for your images. Also would be interesting to compare them with vbindiff  to see how different they are.

Have you looked at any of the interfaces coming off of the NXP chip mentioned by 6thimage in the new 34465A/34470A thread? It looks like the UART, I2C and SPI lines are all routed to traces. I checked the UART on boot with my scope and there's some 115200 baud traffic (3.3V logic) but I haven't gotten around to decoding it yet. It's on my to do list.

Since I've got a somewhat good feel for bringing up my meter from the dead, I may try to erase the entire NAND again and see what happens. Wonder if we'll lose the serial / model number again?

-Tim
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod