TDS540 not booting,  "Flashrom header failed" - Page 1
Forum section: electronics / testgear

author: masterx81
author_rank: Frequent Contributor
timestamp: April 26, 2020, 07:11:35 pm
content: 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 0x4e714ef9Flashrom DSACK-JUMP CODE test failed.Transferring control to the SDM (monitor).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 nvramTomorrow 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....

author: masterx81
author_rank: Frequent Contributor
timestamp: April 27, 2020, 02:56:33 pm
content: 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 isCode:Invalid Flashrom Header checksum = 0x11ec, should be 0x25ebNow 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"

author: masterx81
author_rank: Frequent Contributor
timestamp: April 27, 2020, 09:07:37 pm
content: 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 gotCode:Flashrom Header failed: Bad jumpcode = 0xffffffff, should be 0x4e714ef9So 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.

author: tv84
author_rank: Super Contributor
timestamp: April 27, 2020, 09:50:17 pm
content: I cannot help but I appreciate the progress you've been making. Nice detective work!Hope someone can help with those files.

author: masterx81
author_rank: Frequent Contributor
timestamp: April 28, 2020, 07:28:02 am
content: 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

author: masterx81
author_rank: Frequent Contributor
timestamp: April 30, 2020, 08:59:56 am
content: Tested all traces from flash ic's to the buffers, all ok. I think that will be useful to check the address and data lines with logic analyzer, but i have only a 16ch logic analyzer and here are 32bit buses. I can always dump first the 16msb bits, the do a second boot with the other 16 bit and combining them. But by now i really not think that can be an hardware problem, else how it can pass the crc check of one part of the flash content (the header) and not of another part (the body)? Now all the fash ic's are double checked against the downloaded files, so must be good.

author: analogRF
author_rank: Super Contributor
timestamp: May 01, 2020, 02:07:39 am
content: incredibly I have got the exact same problem as you with my TDS784D. I just posted my findings on the tek forum and tekscope.io groupherehttps://groups.io/g/TekScopes/topic/tds784d_not_booting_never/73387581?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,73387581https://forum.tek.com/viewtopic.php?f=568&t=142222I dont know the history of my scope so I dont know what has caused it. But I hardly think the firmware is actually corrupted.can I ask how you program and check and re-program... the two flash ROM chips? Do you desolder them from the board? seems you have done it a few timesand how did you get the image of each flash ROM? I have the firmware .bin for my scope but how can I program it into the flash ROMs?I dont have GPIB by the wayfollowing your repair log with great interest

author: masterx81
author_rank: Frequent Contributor
timestamp: May 01, 2020, 04:04:34 am
content: Hi! I've slso posted in that forum in the hope to find the firmware files...So, on the first sight i tought that the jumpcode error was caused by a mismatch between NVRAM content and the firmware on the flash, so i've (stupidly...) flashed the flashrom with a version that was matching the nvram version found on the net.But that error with all probability is caused by an error reading the flash content. In my case i suspect that was simply caused by a bad contact of the firmface board connector (i have the flash ic's on a second board).In your case, if the flashrom ic's are placed directly on the main logic board, can be caused by a trace corroded due to a leaky cap. If the main cpu can't read the content of the flash due to a missing data/address line, it thinks that the flash content is corrupted and pop that error.For programming the NVRAM and flash ic's, i've used a willem programmer.I not remember how i've lost the content of my NVRAM, but be aware that i've read on the net that someone have reported to have the content of the nvram chips corrupted simply desoldering them for backup and replacement. The safer way to dump them is via gpib, obviously when the scope boot correctly. In you case the nvram content seem ok (as the li ion battery in nvram chips is still ok).For your problem, i suggest you to follow the traces from address and data pins of the flash to the buffers near the main processor. I was so lucky to find the schematics of my scope, so was easy to follow the data and address traces, but knowing the architecture is possible to find them also without schematics. If you not find the schematics of your precise model, try to find on ko4bb website the schematics for another model with same architecture (like the 520/540). In my case around the main cpu there are several f245 buffers, the signal goes from them to some other ic's near the flashroms.

author: analogRF
author_rank: Super Contributor
timestamp: May 02, 2020, 03:16:17 am
content: Thanks for the tipsMy instrument does not have any SMD electrolytics on the CPU board and acquisition board. Only a handful on the front panel and option 13 and they are all very clean and proper. The boards are all very clean and I cannot spot any crack or damage anywhere. But as I said, I am sure someone has replaced the two NVRAMs.The schematics for this CPU board (679-4003-00) does not exist (in public at least) and is quite a bit different than 520B. This one uses two E28F016SA flash memories.I traced all the 32 data lines from the two flash memories to four bidirectional buffers (74F245) and started checking I/O in those buffers (triggering on the chip enable pin) one by one. I only used my Siglent 2 channel scope with the external trigger and segmented memory to capture the input and output bit on each data line. Before I made sure that during all transactions the direction is always from the flashrom to the data bus (only read is happening) and I also checked to see where the FlashROM CE and OE are activated which was in sync with the buffers CE.One problem is I dont have enough time to view much activity on the flash roms because after 2-3 seconds when the DSACK test fails, there is no activity anymore and everything goes silent on the FlashROM data lines (not on the other side though). In fact I found out during this time only two read attempts are made and both read the exact same data (see my boot log at the bottom) which is 0x2540001c. and after 2-3 hours of turning the instrument on and off 30-40 times I finally confirmed that this data is exactly what is read from the flash rom and transferred to the CPU. So there is nothing wrong with the data bus to the flash ROMs. I got tired and didn't check the address lines but I really dont think the address bus is bad either.I dont know what to look for on the address bus either. If someone has a suggestion, please commentI am curious that where the "should be" data (0x4e714ef9) is located? Is it in the NVRAMs? is it in the bootloader? can someone please comment?Because if it is in the NVRAM, it is possible that whoever replaced them, made a mess of it and the data is corrupt, so the "should be" value is indeed the problembut my gut feeling is that this info is hard coded in the bootloader.Code:RUNNING FROM DRAM.DRAM test passed.Bootrom Header Checksum passed.Bootrom Total Checksum passed.BootRom Check Sum passed.Bus Error Timeout test passed.Kernel Diagnostics Complete.Calling SDM (monitor) Routine.Enabling Bus Control register. Value = 0x67IMR 1 Register test passed.Misc. Register test passed.Timer Interrupt test (Auto-Vector) passed.NVRam DSACK test passed.NVRam Write protected.Flashrom Header failed: Bad jumpcode = 0x2540001c, should be 0x4e714ef9Flashrom DSACK-JUMP CODE test failed.Cannot transfer control to Flashrom.Transferring control to the SDM (monitor).

author: madao
author_rank: Frequent Contributor
timestamp: May 02, 2020, 04:50:00 am
content: Here, TDS540 2.16e , it is newest firmware.TDS520 Firmware by k40bb was from me, it was reading from 12 EEPROM, before i was able write functional unified tektool.But it doesn't run with TDS540-board. I have checked it. Indeed, it must starting sucessful complete(with massive fault, 520 versus 540).Did you know my unified tektool? You can use it.greetingsmatt

author: masterx81
author_rank: Frequent Contributor
timestamp: May 02, 2020, 06:29:23 am
content: Quote from: analogRF on May 02, 2020, 03:16:17 amUhm, i'm quite sure that the jump error is referenced to a flash error, as if i remove the flash board a13 i have an errorCode:Flashrom Header failed: Bad jumpcode = 0xffffffff, should be 0x4e714ef9When i had a data line missing there was the same error but only a single bit difference from the requested data and received data.In your case as the requested data vs received data is so different, i think that can be an addressing failure (it's reading in a totally wrong address).Else, the flashrom content is damaged.In this case a 32ch logic analyzer would be really helpful...---edit---In any case, can be also a buffer failure. Maybe the traces are ok but the logic ic's in the path are bad and corrupt tge data. I think that also in this case must be an addressing failure as request vs received is too different.But, as you not know if the flash content is correct, you can't be sure.Maybe at the time of the change in nvram they have tried to update also the firmware and bricked it. Who knows.A buffer failure can be excluded swapping all the ic's in the path between cpu and flash, if the address error change (and you are sure that isn't a trace) it's a buffer the fault. If remain the same, or flash content or trace missing.

author: masterx81
author_rank: Frequent Contributor
timestamp: May 02, 2020, 06:37:42 am
content: Quote from: madao on May 02, 2020, 04:50:00 amHi!Thanks for the answer!Yes, i know your tool (thanks for the work and for sharing it!), but by now i not have a gpib card. I'm waiting to find an ni pcii/iia isa card to put in an old pc for do also the calibration procedure...So, i was so wrong that 520 vs 540 firmware was the samemy bad, due to that short on u406 i not have neither a valid backup of my flashromDid you think that the crc calculation must be good also with the wrong firmware image?Really thanks for the firmware image!!I'll try to put it on my flash ic's as soon as possible!If not work, the next thing that i try is to put my 16ch LA to the data and address buses for check if some lines are stuck...Maybe, if not asking too much, did you have also a flash dump for older firmware versions?---EDIT---I'm sorry, but i'm unsure on the content of the backp that you have posted.The backup of my chips is 131072bytes. multiplied by 12 ic's is 1572864. and match with the file size of your backup. But did you know "what part goes where" in the various chips? From the schematics i would thell that they are addressed in order (U400, U401, U402, etc) but i'm not sure.What worry me is the start of the file, that i suppose must be similar to the content of my backup (that it's quite similar to the backup of the 2.16e for the TDS520).Both files (my backup of U400 for 540 and the ko4bb U400 fo 520) starts with an 0xF9.If i look the TDS540 fw 2.16e that you have posted, i see that the 0xF9 if present but, but only after 3 bytes from the start of the file. Also the copyright string (different from the other 2 files that i have, as starts with a "c" copyright symbol) seem starting 3 bytes after the other 2 files. It's normal?

author: madao
author_rank: Frequent Contributor
timestamp: May 03, 2020, 07:23:19 pm
content: Yes, CRC must fit, then it can start.CRC fail -> start into bootloader-mode and wait on new firmware-file.Sad, Firmware 1.1 is away, i want collect all TDS firmware, also old.Greetingsmatt

author: masterx81
author_rank: Frequent Contributor
timestamp: May 03, 2020, 08:05:01 pm
content: I think that mine had an old firmware, i'm missing only u406 (but obviously made the whole backup useless).I've tried to search on the 11 valid backups of my flash ics, but wasn't able to find the version string, so i not know what version i had.So i try to flash your 2.16e backup in this way also if seem that there is a 3byte offset. I think that i need to split your file and desolder/program/resolder the flash as by now i still not have the gpib card. Seem quite difficult to find on ebay here in europe.

author: madao
author_rank: Frequent Contributor
timestamp: May 04, 2020, 06:38:00 am
content: Other solution: you send ROM-PCB to me and i program it with newest firmware and check it. At end , you become it again.Interessing?Matt

author: masterx81
author_rank: Frequent Contributor
timestamp: May 04, 2020, 09:09:03 am
content: Hi! Yes, interesting option. So i'm sure that the flash content is ok (so i'm sure it's a problem with the dram board). I will try one more time to flash them individually, and if not work i send to you the whole firmface board! I send you a pm when i'm ready so we can organize. I see that you are in europe so the shipping will not cost too much.Thanks for the help!

author: madao
author_rank: Frequent Contributor
timestamp: May 05, 2020, 04:25:46 pm
content: Yes, i live in germany and you in italia. This is why, i make a proposal to you :-), but i'll sell my TDS540 in 2 week. If it is sold, i can't flash you module.Write me a PM, if you want my help.greetings & stay healthymatt

author: masterx81
author_rank: Frequent Contributor
timestamp: May 10, 2020, 09:53:38 am
content: Tried to flash, but i get a bad jumpcode (neither arrive to the header cnc).That dump it's working for sure?Eventually i've found another not working cheap tds540, maybe i can use it's firmface board.If i've well understood the flash boot sequence is:Jumpcode checkHeader crcBody crc... never gone after this

author: chronos42
author_rank: Regular Contributor
timestamp: May 11, 2020, 09:59:31 am
content: If you need a pre-programmed firmface board I have one as sparepart and can ship it to you. Send me a PM if you are interested. It is pre-programmed with the latest TDS 500 Firmware (2.09E).

author: masterx81
author_rank: Frequent Contributor
timestamp: May 12, 2020, 05:59:46 am
content: Hi! I see if i can get the other tds540 cheap and i'll let you know!What you mean for TDS500 firmware? If i've well unterstood 520 and 540 fw are different.Thanks!

author: chronos42
author_rank: Regular Contributor
timestamp: May 12, 2020, 07:50:24 am
content: Quote from: masterx81 on May 12, 2020, 05:59:46 amSorry, that was a typing error, I meant TDS 540 of course.

author: hansgt21
author_rank: Newbie
timestamp: December 26, 2024, 06:20:45 pm
content: Hi,I recently picked up the hobby of ( trying to ) repairing old test equipment and got a TDS540.I have been trying to get it to boot up but it is stuck with a flashrom checksum error.It seems somehow the firmware got compromised.All caps have been replaced and the boards ( A10, A11, display ) look good with no apparent visual damage.NVRAM has been replaced with a preprogrammed version from kellyjo_13 / ebay.After reading to multiple posts on different forums I guess I am more confused than before...My questions are :Where can I download a working firmware version for my TDS540 ?How to update the FW ( in Windows ? , DOS ? )Which ( if any ) GPIB to USB converter would work or do I need an old 488.2 card ?The boot message looks as follows :Enabling Bus Control register. Value = 0x67IMR 1 Register test passed.Misc. Register test passed.Timer Interrupt test (Auto-Vector) passed.NVRam DSACK test passed.NVRam Write protected.Flashrom DSACK and JumpCode test passed.Invalid Flashrom Header checksum = 0x3efc, should be 0xfefbFlashrom Checksum test failed.Cannot transfer control to Flashrom.Transferring control to the SDM (monitor).Any help is very much appreciated.Hans