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.