[Solved!]Looking for firmware dump for Tek THS3024.(How to repair firmware)

[fzabkar]

The problem is how to recover the part from $4EC0-$FFFF, which we believe has its serial number and calibration constants written to it.

There must be some whitespace between 0x4EC0 and 0x8000. This is so that a firmware update can "grow". Also, both upper and lower ROMs must be corrupt, but not consistently so, otherwise I would not have been able to reconstruct those 4 x 8KiB blocks.

Code: [Select]

Offset(h) 00   02   04   06   08   0A   0C   0E

00008000  FFFF 0200 FFFF 0000 FFFF 0000 FFFF DC0D
00008010  FFFF 0044 FFFF 0000 FFFF 0000 FFFF 0000
00008020  FFFF 1348 FFFF 7011 FFFF 0100 FFFF 6900
........
0000A000  0004 FFFF C419 FFFF 0100 FFFF AF6C FFFF
0000A010  7600 FFFF 0000 FFFF 0000 FFFF 0000 FFFF
0000A020  0100 FFFF CE00 FFFF 2000 FFFF 5500 FFFF

[coromonadalix]

can this 2014 FW and flash tool help ?   attached


Firmware v01.02 corrects the problem happened during probe calibration. Before the change, Waveform is not visible during probe calibration when certain languages are selected. Less than 2 divisions are visible due to pop-up window size. Detail …

Firmware | P/N 066136603 | Date: Monday, March 17 2014

[fzabkar]

I examined the firmware payload and extracted the metadata for the DATA BLOCKs. I then looked for "holes", ie areas that are not touched by the update.

For example, bytes 0x20dbc2 - 0x20dbc3 are untouched.

Code: [Select]

,#H4020c000,#H1000
,#H4020d000,#Hbc2
,#H4020dbc4,#H1000
This is the corresponding area in dead.bin:

Code: [Select]

Offset(h) 00   02   04   06   08   0A   0C   0E

0020DBB0  0000 0000 0000 0000 0000 0000 0000 0000
0020DBC0  0000 FFFF 0000 4902 0000 0944 0000 0000
               ^^^^
0020DBD0  0000 0000 0000 0000 0000 0000 0000 0000
Is this the original data, or is it now corrupt? Was this area ever programmed, in which case 0xFFFF would be the normal erased state of this word? Have I introduced a red herring?

[fzabkar]

Ruby.ldf

Code: [Select]

,#H40000000,#H28
,#H40000028,#H4
,#H40000030,#H8
,#H40000040,#H30
,#H40000080,#H1000
dead.bin

Code: [Select]

Offset(h) 00   02   04   06   08   0A   0C   0E

00000000  1122 3344 5566 7788 5555 5555 AAAA AAAA
00000010  3333 3333 CCCC CCCC 0F0F 0F0F F0F0 F0F0
00000020  FF00 FF00 00FF 00FF 3000 0040 FFFF FFFF
00000030  4000 0040 5800 0040 FFFF FFFF FFFF FFFF
00000040  0080 0040 0040 0000 00C0 0040 0040 0000
00000050  0000 0000 0000 0000 0000 3F40 0040 0000
00000060  0040 3F40 0040 0000 0000 0000 0000 0000
00000070  0000 0000 0200 0000 0020 0000 0200 0000
These words have not been reprogrammed by the update. Are they corrupt?

Code: [Select]

Offset(h) 00   02   04   06   08   0A   0C   0E

00000020                                FFFF FFFF
00000030                      FFFF FFFF FFFF FFFF
........
00000070  0000 0000 0200 0000 0020 0000 0200 0000

[squadchannel]

omgggggggggggggggggggggggggggg
I will describe the details later, but it is now recognized when I rewrote it appropriately. I am extremely happy!
We will summarize later, as we do not know how the changes we made in the binary affect it.
We will leave the binary that we were able to launch. It is not the final binary, so please do not try it with your own scope.

I haven't had lunch, so I'm going to go eat.

 

[coromonadalix]

congratz   

and yes  if you can  tell us  your latest recovery story ... to help others in the future   

[fzabkar]

Congratulations from me, also. For a while it was looking like you were at a dead end.

That looks like a very nice unit (I want one, too). Let's hope there are no other problems. :-)

https://assets.rs-online.com/v1698844007/Datasheets/4f5c6ab212d4cf09e8376a595b77b528.pdf

[squadchannel]

I have used it several times and it seems to work fine.
For now, the firmware build is complete. Thanks to all those who helped.

Here is a summary of how to create the firmware.
Although unconfirmed, I believe the same method can be used to restore the Fluke 190 Series II (190-xxx).

Please make sure you have created a directory to do the work. Alphanumeric, of course. Do not use spaces.

• Dump the firmware from the main unit. There are two FlashROMs that store the firmware, and the firmware is divided and written to them.
  We call them Upper/Lower with the BNC input on top. Both can be dumped using the TL866 and an adapter.
  
  
• Combine the binaries dumped from ROM into one. We have created a "2to1.exe" to make this easy. The source file is also attached.
  
  2to1.exe upper.bin lower.bin
  
  Drag and drop Upper/Lower into 2to1.exe to generate an integrated rom.bin.
  Be sure to check the contents. When you open the binary, from the beginning it should be 11 22 33 44 55 .....
  If 33 44 11 22 .... then the Upper/Lower paths are reversed.
  
  
  
• Download the file for firmware update from the official website (Fluke/Tek).
  In case of Tek THS3000, you can download from https://www.tek.com/ja/support/software/firmware/ths3014-software-1(THS3000_FW_v0102_Installer.zip).
  
• Extract only "Ruby.ldf" in the downloaded updater. In the case of Fluke, it is "Tetra.ldf".
  
  5. Download "FlukeFW2Bin.exe" which creates bootable firmware from the update file. You can download it from the following topic
  https://www.eevblog.com/forum/microcontrollers/fluke-19xbcii-firmware-to-binary-converter/msg1280562
  
• Drag and drop "Ruby.ldf" or "Tetra.ldf" into "FlukeFW2Bin.exe" and run it.
  
  FlukeFW2Bin updateFile.ldf
  
  After execution, "Ruby.ldf.DataBlock.bin" and "Ruby.ldf.ExtensionData.bin" will be created directly under the directory.
  ExtensionData.bin" is unnecessary. You may delete it.
  Only "Ruby.ldf.DataBlock.bin" is used.
  
• Now comes the important part. Integrate the corrupt firmware "rom.bin" and the generated firmware "Ruby.ldf.DataBlock.bin".
  Calibration, serial number, and model name, all three of which are stored in $8000-$FFFF. This range can be further divided into four parts
  $8000-$9FFF
  $A000-$BFFF
  $C000-$DFFF
  $E000-$FFFF
  The blocks are divided into If $8000-$9FFF contains the "correct binary", the calibration, serial, and model name are recognized correctly.
  If not correct, in my case (THS3024), the model name is "THS3014", the serial number is "SERIAL NUMBER", and the calibration is "Invalid".
  
  For correct recognition, there is a checksum at the end of each block. The checksum values must be matched correctly.
  There are two types of checksums,
  The result of adding the bytes from $0000 to $1FF7 (in the binary range of the block) goes into $1FF8,
  The result of XORing the bytes from $0000 to $1FFB (in the binary range of the block) (including the result of the addition) is placed in $1FFC.
  
  checkSUM.exe" and "checkXOR.exe" have been created to perform the checksum calculation. The source is also available.
  Extract the four blocks, create a binary, and drag and drop it. The result will be output.
  
  Check the checksums and if they match, congratulations. You can proceed to the next step.
  
  If this calculation does not match, it may be damaged somewhere. In my case it was corrupted.
  If it is corrupt, it can be restored based on information from other blocks, but there is a condition: it can only be restored between blocks of $8000 and $A000, and between blocks of $C000 and $E000. (Probably)
  Also, the XOR checksums in the $C000 and $E000 blocks do not match. We believe the calculation method is probably different.
  We have also checked the case where there are only two blocks ($8000-$BFFF and $C000-$FFFF). In this case also, the XOR checksum results do not match.
  
• Change one more location. This is the $0070-$007F part.
  This part can be filled with 00h or copied from a corrupted ROM. Either way, it worked fine.
  In the generated firmware, there are "FE" and "F4" at the beginning of the area, but this did not work.
  
• Ruby.ldf.DataBlock.bin", which was integrated in steps 7 and 8, needs to be split into two parts for writing to the flash ROM.
  We created "1to2.exe". Source available.
  
  1to2.exe rom.bin
  
  Drag and drop the merged "Ruby.ldf.DataBlock.bin" and it will be split into upper.bin and lower.bin.
  There is no confirmation that the files will be overwritten, so it is better to create a new folder and use it.
  
• Write the upper/lower created by the split, solder it, and check if it works.
  

The above is how I have done it with success.

There is a lot of mystery about how the checksums are calculated. In my case, the XOR checksum did not match for the $C000 and $E000 blocks.
After the serial was successfully recognized and succeeded, I used the updater to try it out, and the aforementioned blocks went from four to two. It seems to have been rewritten, and XOR is no good.

I also don't know what $0070-$007F is doing.

Here's what I've got for now. fzabkar, thanks. Appreciate your cooperation.

[asis]

Hi,

Great job.
Congratulations.

-

In the update (in the body of the flasher) there is evidence that the scope can be updated to work with BUSHEALTH options (listening to various bus).
At least this trick worked on FLK199C to -> FLK225 v.804 and may be useful.
Also, expanded language support has been activated.
The way to activate it is to edit FlashTool.ini before the SW update program flasher is launched.
Now that you feel confident, you can afford it.

Good luck!

[squadchannel]

Hi,

Great job.
Congratulations.

-

In the update (in the body of the flasher) there is evidence that the scope can be updated to work with BUSHEALTH options (listening to various bus).
At least this trick worked on FLK199C to -> FLK225 v.804 and may be useful.
Also, expanded language support has been activated.
The way to activate it is to edit FlashTool.ini before the SW update program flasher is launched.
Now that you feel confident, you can afford it.

Good luck!

BUSHEALTH is also present in THS3024/3014. It is blocking the function somewhere.
Perhaps it is blocking between $0070-007F, or a calibration block. I'd like to try if I have time.

AS-i, RS-232, RS-485, Foundation(?), CAN, Ethernet, Modbus, Profibus