Products > Test Equipment

TDS540 not booting, "Flashrom header failed"

(1/5) > >>

masterx81:
Hi! Long time ago i bought a failed TDS540 (leaky caps) for try to repair. Now, years later, i've time to repair it (thanks to coronavirus, i'm at home as the worplace is closed  >:( ).
When i got it, i have backed up both nvram and eprom. Then modified the dallas chip adding 2 cr2032 batteries.
At that time the scope was starting correctly, with an error on acquisition board. In the meantime i've bought the debugging interface (the one with the SCN68681 IC). Now i'm trying to power it on, but never do the boot correctly.
The error is:

--- Code: ---Flashrom Header failed: Bad jumpcode = 0x4f714ef9, should be 0x4e714ef9
Flashrom DSACK-JUMP CODE test failed.
Transferring control to the SDM (monitor)

--- End code ---
.
I've verified the content of both eprom and dallas chip and are the same as when i've backed up them.
So, what can cause this failure?  Thanks!

----EDIT----

My memory is not so good, but seem that i've recovered some details on what i've done years ago.
Seem that analyzing the bin files of the nvram that i have, none of them is a backup of my scope. Both seem files that are downloaded from internet. One is from unknown source, the one that i'm using is a backup (EPROM + NVRAM) of a 2.16f version. Maybe this NVRAM and EPROM doesn't match with the code in the flash roms on the firmware board, so the error. Seem that i wasn't able to backup the original content of the nvram. I not remember is the battery failed or something else.
So, i have 2 options: Update the flash roms to the 2.16e version, or get a backup of the nvram of the EPROM/flashrom that i have. On the EPROM there is wrote: 160-8505-00 A11U1331 VER 1.5, i need to find an NVRAM matching this version.

---REEDIT---

On KO4BB website i've found the flash files for firmware 2.16e for the 520. The board code for the 520 is 671-1701-01, the same as my 540. I think that the firmware is the same for both. Maybe the model (520/540) is stored in the nvram
Tomorrow i'll try to update the firmware for match the eprom and nvram. In any case i do a backup of my flash memories before doing anything.

The only problem is that after all i need to do a calibration. I have software and hardware, but the software seem only for firmware ver 1.10 and 2.09....

masterx81:
Starting to hate this thing. I've flashed all the chips (program &verify) and now the DSACK and JumpCode test are good, but now the error is

--- Code: ---Invalid Flashrom Header checksum = 0x11ec, should be 0x25eb
--- End code ---
Now i try to desolder the chips and verify but i'm sure that are all well programmed.
The worst thing is that while dumping the flash content of  U406 i've not noticed a really thin residue of tin that shorted 2 pins, that obviously came up during the programming phase, so i can't neither go back in fw version as i'm quite sure that the reading of the device was not correct. For exclude errors i've read and verified the read, but with the pin shorted both reading came up wrong the same.
Now i'm a bit in pain as i'm stuck...

----EDIT----

Rechecked the programming of the flash ic's, one was not well programmed. But has not resolved much, as now i have:

--- Code: ---"Invalid Flashrom Body checksum = 0x5751, should be 0xd97"
--- End code ---

masterx81:
Some more observations:
As the problem was from the start caused by the firmware (so the code in the flashroms), and i'm sure that the code previously was correct on the flashroms, i'm starting to think that wasn't in the nvram code and neither the eprom code the problem,  but something between the cpu and the flashroms.
I ignore what was the error of the jumpcode, but i think something inside the flash. Searching the net about this error i've found someone that without firmface board got

--- Code: ---Flashrom Header failed: Bad jumpcode = 0xffffffff, should be 0x4e714ef9   
--- End code ---
So as my error was simply a one bit error(asked 0x4e714ef9 received 0x4f714ef9) seemed like there was one data line of the 32bit bus not working (Next try is to boot the scope without firmface to see the error)
After the flash of the new firmware version, that error has gone.
When there was one chip programmed badly, it was not passing the crc check of the header of the firmware (that can be caused also by a data line not working), but after have found the falsh ic with the wrong code, also that error has gone.
So in some way (that i really not understand) the data bus problem has fixed itself, else wasn't possible to compute a crc check. I suspect that the crc of each section is in the flash (in well known locations), and it compare the crc stored with the one calculated from the other memory locations (for now i've seen header and body).
So, the error that i have now about the crc of the body (that seem read after the header) can be caused by the firmware files that are not ok (as now i'm sure that the flash content is double check verified against the downloaded files).
In any case i've checked if the data and address line a0...23 and d0...31) from the buffers to the firmware board and are all ok and (now) no lines are interrupted.
The firmware that i've downloaded must be ok in some ways (as the header crc is well computed) but there must be some problem somewhere else.

At this point, someone that know well this infernal thing, can confirm my toughts?

And also, where i can find a secure way to obtain the firmware files (maybe of firmware 2.16e) for my tds540?
Seem that it's easy to obtain via gpib, i've seen a script that can do it easily.

Someone, please, can help me a bit to fix this scope? I really not like the idea to give up.

tv84:
I cannot help but I appreciate the progress you've been making.  Nice detective work!   :clap: 

Hope someone can help with those files.

masterx81:
I not know enough about this scope, so the repair is difficult. The bad thing is that when i've fixed the logic board, i'm sure to have to fix also the acquisition board, as the caps had leaked a lot and i'm sure that some traces are corroded. It's a log time job, and without the right knowledge and the correct things (ie firmware files) it's INCREDIBLY time consuming.
And at the end, i have no warranty to be able to fix it, but i really want to try. It's a quite good scope, would be great have it working stacked near my other instruments

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod