| Electronics > Repair |
| [Solved!]Looking for firmware dump for Tek THS3024.(How to repair firmware) |
| << < (3/8) > >> |
| squadchannel:
Good morning. It was not recognized correctly. Disappointing. The binaries in the area starting with $6700 have binaries similar to $4700. We believe this is probably the binary recognized as THS3014. I am not going to give up until I can find someone who can provide a firmware dump, but this firmware may be unrecoverable given that critical parts are corrupted. I have contacted Tektronix to see if I can purchase this board or get repair service. You probably cannot purchase the board by itself. Repair service should not be cheap. I will wait for them to contact me in the meantime. I should have bought THS7xx. I'll try my best, though it's a lot of work, and I'm sure it will help with the THS3014/3024 repair. |
| fzabkar:
--- Quote from: squadchannel on June 08, 2024, 04:12:54 am ---The binaries in the area starting with $6700 have binaries similar to $4700. We believe this is probably the binary recognized as THS3014. --- End quote --- I think those two regions are probably identical. This begs the question, if the data prior to 0x4EC0 was included in the firmware update, then why wasn't the "identical" area also included? In fact I believe that this area is part of the code, even though its tabular nature suggests that it is some kind of data area. I now suspect that the area between 0x4EC0 and 0x6EBF is meant to be zero-filled, but is instead filled with "phantom" data as a consequence of corruption. Otherwise the firmware update makes no sense to me. When you get your ROM extender board, I have an idea that I'd like to try. Basically it involves writing the 0xC000 and 0xE000 blocks with the second, slightly different copy, the first with a 0x4A XOR checksum, the second with 0x71. I'm theorising that the firmware tests the integrity of the first copy (0xC000) and reverts to the second copy (0xE000) if it fails. So in effect it needs one good copy from 0x8000/0xA000 plus one good copy from 0xC000/0xE000. |
| asis:
Hi, The ASIC contains a mask (OTP). Most likely, at the stage of executing the SW update, its procedure was incomplete or an incorrect SN was entered. Check the SN match on the back cover of the scope and in the dump you considered. To read SN try using the command: [COM: 1200;N;1;8;N] QI 11 (QI_space_11) QUERY INSTRUMENT = S/N In older versions of Fluke, to enter the mask checking mode, hold down the ^> keys, turn on the scope, enter “X” until 0 (zero) appears, enter the "ID0" directives. While in mask mode, you can check the RAM states. The correct thing to do is to connect the AC adapter. |
| squadchannel:
--- Quote from: asis on June 08, 2024, 10:17:28 pm ---Hi, The ASIC contains a mask (OTP). Most likely, at the stage of executing the SW update, its procedure was incomplete or an incorrect SN was entered. Check the SN match on the back cover of the scope and in the dump you considered. To read SN try using the command: [COM: 1200;N;1;8;N] QI 11 (QI_space_11) QUERY INSTRUMENT = S/N In older versions of Fluke, to enter the mask checking mode, hold down the ^> keys, turn on the scope, enter “X” until 0 (zero) appears, enter the "ID0" directives. While in mask mode, you can check the RAM states. The correct thing to do is to connect the AC adapter. --- End quote --- Immediately after purchase, I activated UHM when it was in bootloop and confirmed that the correct serial came up."404024382332" Later, when the UHM could be booted but the serial was not recognized, the UHM's QI11 response was "SERIAL NUMBER" instead of "40402424382332". Maybe QI11 is not reading within the mask, but the flash ROM. --- Quote from: fzabkar on June 08, 2024, 05:50:03 pm --- --- Quote from: squadchannel on June 08, 2024, 04:12:54 am ---The binaries in the area starting with $6700 have binaries similar to $4700. We believe this is probably the binary recognized as THS3014. --- End quote --- I think those two regions are probably identical. This begs the question, if the data prior to 0x4EC0 was included in the firmware update, then why wasn't the "identical" area also included? In fact I believe that this area is part of the code, even though its tabular nature suggests that it is some kind of data area. I now suspect that the area between 0x4EC0 and 0x6EBF is meant to be zero-filled, but is instead filled with "phantom" data as a consequence of corruption. Otherwise the firmware update makes no sense to me. When you get your ROM extender board, I have an idea that I'd like to try. Basically it involves writing the 0xC000 and 0xE000 blocks with the second, slightly different copy, the first with a 0x4A XOR checksum, the second with 0x71. I'm theorising that the firmware tests the integrity of the first copy (0xC000) and reverts to the second copy (0xE000) if it fails. So in effect it needs one good copy from 0x8000/0xA000 plus one good copy from 0xC000/0xE000. --- End quote --- I'll experiment when I get it. |
| squadchannel:
I have never run the QI11 command for UHM after understanding the checksum. Now that I understand it, if I run QI11 again and it recognizes it correctly, it may mean that the checksum calculation method is correct. Because right after I purchased the 3024, the ROM binary that I was able to boot anyway had the $4eco-ffff area, which is supposed to contain device-specific data, in a blank state (00). Naturally, the serial connection was not recognized, but the device could be booted. If you ran UHM QI11 in that state, then it is not surprising that it was not recognized correctly. Or maybe the QI11 thinks it is reading the serial in the flash ROM, but there is actually an EEPROM inside the main SoC. If so, it's even harder. Hell. I do not understand where and how UHM verifies and recognizes the serial. It is also strange that the serial is correctly recognized when the firmware is corrupted. If the checksum calculation method we are considering now is correct, it is because the block with the corrupted firmware serial is also corrupted. |
| Navigation |
| Message Index |
| Next page |
| Previous page |