[Solved!]Looking for firmware dump for Tek THS3024.(How to repair firmware) - Page 1
Forum section: electronics / repair

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 04, 2024, 05:00:25 pm
content: update 15/06/2024: Problem solved.https://www.eevblog.com/forum/repair/looking-for-firmware-dump-for-tek-ths3024/msg5542145/#msg5542145I recently acquired a THS3024. It is, of course, a faulty item.It arrived. It should have been an easier fix, but I was surprised when it started up and the buzzer "beep" and looped. I was convinced it was a tough job.I dumped the firmware with TL866.Oh, the contents are corrupted. I am trying to restore it somehow.The saving grace is the post below. It is a tool that can generate the contents of the firmware in the flash from the file for update.https://www.eevblog.com/forum/microcontrollers/fluke-19xbcii-firmware-to-binary-converter/msg1280562I was able to use this tool to write the generated firmware and boot.But, of course, the generated file is missing the serial and the data that identifies the 3014/3024.I know where it is, but when I copy and merge that part from the corrupted dump, it is not recognized. This is because it recognizes it as 3014 when it should be 3024. Bandwidth is limited.If anyone can help me, I would appreciate it.

author: fzabkar
author_rank: Super Contributor
timestamp: June 04, 2024, 11:02:48 pm
content: Can you upload the dump and the regenerated flash image? Perhaps someone may know how to edit the missing data.

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 05, 2024, 06:45:54 am
content: Attached.The generated image has a large "00" chuck. That is where the device-specific data is located. It is not overwritten by the updater, so it is zero-filled.$4EC0-$0FFF:I was able to confirm the character strings such as serial and model number (THS3024). However, the part that corresponds to the upper ROM has been partially damaged and is now FF. I am not sure if this is normal or not, so I am looking for someone who can read out the ROM.I have tried merging this section of data with the generated ROM, but it seems to be recognized as corrupt and rewritten.If it is detected as corrupt, it appears to be initialized with the data in $1C12B0-$1C17FF, described below.I think there is a checksum something somewhere, but I have no idea.However, even though it is damaged, it also feels normal. In any case, it is hard to tell without being able to compare.$1C12B0-$1C17FF:Perhaps initialization? There is data for.$1C2000-$1C3FFF:PreCal? There is a mode that can calibration without instrumentation, and if you take the difference between before and after the run, it appears to be rewritten.$384D64: after this is probably the part used as storage for screen captures, etc., so it does not exist. I captured the screen after startup and saved the .bmp. There was a magic number "42 4D".

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 05, 2024, 08:29:33 am
content: Incidentally, the board design is very similar to the Fluke 190 Series II.components are visually identical, although some of the components used are different.main chip also says Fluke, so it is a Fluke OEM.THS3024(flash was removed):Fluke 190 Series II(from service manual):

author: fzabkar
author_rank: Super Contributor
timestamp: June 06, 2024, 06:54:09 pm
content: It seems to me that the section from 0xC000 to 0xFFFF should be a copy of the section from 0x8000 to 0xBFFF. Perhaps the solution is to replace the first 16KiB section with the second 16KiB section in your dead.bin dump?I believe each 16KiB section has two checksums at the end, but I can't make sense of them. Hopefully the second section is not corrupt.Code:Offset(h) 00 04 08 0C0000FFF0 FFFFFFFF FFFFFFFF 9B000000 71FFFFFFEdit:I think both sections are corrupt, but I'm wondering if there is a way to combine the good areas of each?Edit #2:Actually, I think there are 4 x 8KiB blocks, each with a pair of checksums at the end. I don't think they are meant to be identical, but it may still be possible to repair one section by using parts of another.Edit #3:I think I see the pattern. The 3rd and 4th blocks are constructed from the 1st and 2nd blocks.Code:Offset(h) 00 02 04 06 08 0A 0C 0E00000000 FFFF 0200 FFFF 0000 FFFF 0000 FFFF DC0D 0x8000_9FFF.bin00000000 0004 FFFF C419 FFFF 0100 FFFF AF6C FFFF 0xA000_BFFF.bin00000000 0004 0200 C419 0000 0100 0000 D86B 210E 0xC000_DFFF.bin00000000 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0xE000_FFFF.bin

author: fzabkar
author_rank: Super Contributor
timestamp: June 06, 2024, 08:44:22 pm
content: I performed a bitwise AND on the first two blocks and got the attached file. The first of the two checksum dwords at the end of the file is 0x0000002C. This matches the 8-bit sum of all the bytes preceding the checksum dword.The 3rd and 4th blocks don't seem to fit my hypothesis, though ...What if you were to copy the contents of the 8KiB AND-ed file to each of the 4 sections? I believe that the 3rd and 4th sections are meant to be identical, but different from the first two sections. Perhaps they contain the previous set of calibration data?Edit:The final dword is computed by calculating the XOR checksum of all the preceding bytes, including the previous checksum. In the present case it is 0x72, so the final dword is 0xFFFFFF72 (little-endian).

author: fzabkar
author_rank: Super Contributor
timestamp: June 07, 2024, 04:17:29 pm
content: The 8KiB block at 0xC000 has corruption in this area:Code:Offset(h) 00 02 04 06 08 0A 0C 0E0000D270 FFFF 6614 FFFF 0100 FFFF 00000000D280 0000 6714 0C00 0100 0A00 0000 FFFF 68140000D290 FFFF 0100 FFFF 0000 FFFF 6914 FFFF 0100........0000D9A0 FFFF 0062 FFFF 0200 FFFF 0000 FFFF D9080000D9B0 FFFF 0040 FFFF 1202 FFFF 0300 FFFF 00000000D9C0 FFFF 0000If I repair it with the corresponding area of 8000_AND_A000.bin, the 8-bit sum (0x9B) is then correct, but the XOR-8 checksum is not (0x4A instead of 0x71).Code:Offset(h) 00 02 04 06 08 0A 0C 0E0000DFF0 FFFF FFFF FFFF FFFF 9B00 0000 71FF FFFFI have attached my checksum calculator and bitwise AND-ing tool.Edit:There appears to be an additional corrupt section between 0x4EC0 and 0x7FFF. I have no idea how to repair this.

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 07, 2024, 04:39:35 pm
content: Quote from: fzabkar on June 07, 2024, 04:17:29 pmI too found that corrupted area.I rewrote it and confirmed that the checksum is 0x9B,4A. 9B is correct, but 4A does not match, I believe that the copied part is different between $8000 and $C000 blocks, or some byte is corrupted.Quote from: fzabkar on June 06, 2024, 08:44:22 pmThe checksum calculation does indeed match. I copied the attachment to all four blocks.I booted it up and both the serial and model name are still initialized. I also tried reading the file to see if the initial values were overwritten, but they were not overwritten and remained at 3024. I am not sure if this is because the checksum is correct, but it may be that it is considered correct.There was no difference in the contents of the flash ROM before and after writing.My guess is that maybe it is only identifying the $8000 block.The fact that it was not overwritten and remains intact means that it may still be affected by other corrupted areas and not correctly identified.The binary that exists in $6700 is suspect. Possible contents may be storing bandwidth, sampling rate, option flags, etc.This part could be very difficult to recover. I do not see any duplicated blocks around. It may be faster to buy a working one and dump it.I am afraid to expose the board to hot air repeatedly, so I am currently ordering a ROM extender board. Then we will resume testing.

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 07, 2024, 04:51:38 pm
content: The binary we tested does not include the binary that exists in $6700.I just used the attached $8000 restore binary, copied it to 4 blocks and wrote it to ROM.I will test the $6700 & $8000x4 block copy when I wake up in the morning. I hope it works....

author: fzabkar
author_rank: Super Contributor
timestamp: June 07, 2024, 05:31:55 pm
content: Quote from: squadchannel on June 07, 2024, 04:51:38 pmI don't hold out any hope. The corruption looks very extensive. In fact, I'm having a very hard time trying to understand how the flash ROM became corrupted in this way.

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 08, 2024, 04:12:54 am
content: 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.

author: fzabkar
author_rank: Super Contributor
timestamp: June 08, 2024, 05:50:03 pm
content: Quote from: squadchannel on June 08, 2024, 04:12:54 amI 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.

author: asis
author_rank: Frequent Contributor
timestamp: June 08, 2024, 10:17:28 pm
content: 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/NIn 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.

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 08, 2024, 10:34:55 pm
content: Quote from: asis on June 08, 2024, 10:17:28 pmImmediately 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 pmI'll experiment when I get it.

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 08, 2024, 11:20:20 pm
content: 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.

author: fzabkar
author_rank: Super Contributor
timestamp: June 08, 2024, 11:52:39 pm
content: What is the part number of the two flash chips?

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 09, 2024, 03:23:41 am
content: Quote from: fzabkar on June 08, 2024, 11:52:39 pmSST39VF6401B

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 09, 2024, 03:38:06 am
content: I found an interesting entry in the datasheet.Perhaps a security ID is set? I'll check it out.Quote

author: fzabkar
author_rank: Super Contributor
timestamp: June 09, 2024, 04:14:02 pm
content: To me, the corruption is bothersome because it appears to affect both flash ICs in the same way. That is, the even 16-bit words appear to be affected. It makes me wonder whether these chips have some inherent address decoder fault.dead.binCode:Offset(h) 00 02 04 06 08 0A 0C 0E0033D440 454E 4869 4500 0056 4E41 6576 0052 2048 ENHiE..VNAev.R H0033D450 414D 6800 5245 4C65 4D45 6C20 454E 6768 AMh.RELeMEl ENgh0033D460 4500 2D4C 4E41 656C 0044 6967 4554 562D E.-LNAel.DigETV-0033D470 4445 7665 5445 4869 454C 0056 4500 6576 DEveTEHiEL.VE.ev0033D480 4C45 2048 0044 6800 4554 4C65 4445 6C20 LE H.Dh.ETLeDEl0033D490 5445 7700 454C 4C65 4500 6C20 4C45 7700 TEw.ELLeE.l LEw.0033D4A0 0044 4C65 4554 6C20 4445 7700 5445 4C65 .DLeETl DEw.TELe0033D4B0 454C 6C20 4500 7700 4C45 4C65 0044 6C20 ELl E.w.LELe.Dl0033D4C0 4554 7700 0000 4C65 0000 6C20 0000 7700 ETw...Le..l ..w.0033D4D0 0000 4C65 0000 6C20 0000 7700 0000 4C65 ..Le..l ..w...Le0033D4E0 0000 6C20 0000 7700 0000 4C65 0000 6C20 ..l ..w...Le..l0033D4F0 0000 7700 0000 4C65 0000 6C20 0000 7700 ..w...Le..l ..w.0033D500 0000 4C65 004C 6C20 656C 7700 4C65 4C65 ..Le.Ll elw.LeLe0033D510 6C3A 6C20 6576 7700 3A00 4C65 7665 6C20 l:l evw.:.Level0033D520 004C 7700 656C 7461 4C65 0044 6C3A 6120 .Lw.eltaLe.Dl:a0033D530 6576 4461 3A00 2083 7665 6174 004C 8300 evDa:. ƒveat.Lƒ.0033D540 656C 7461 4C65 0044 6C3A 6120 6576 4461 eltaLe.Dl:a evDa0033D550 3A00 2083 7665 6174 004C 8300 656C 7461 :. ƒveat.Lƒ.elta0033D560 5374 0044 7573 6120 5374 4461 7573 2083 St.Dusa StDaus ƒ0033D570 5374 6174 7573 8300 5374 7461 7573 0052 Statusƒ.Sttaus.R0033D580 5374 6500 7573 7365 5374 6973 7573 5269 Ste.usseStisusRigenerated.binCode:Offset(h) 00 02 04 06 08 0A 0C 0E0033D440 6C20 4869 6768 0056 2D4C 6576 656C 2048 l High.V-Level H0033D450 6967 6800 562D 4C65 7665 6C20 4869 6768 igh.V-Level High0033D460 0056 2D4C 6576 656C 2048 6967 6800 562D .V-Level High.V-0033D470 4C65 7665 6C20 4869 6768 0056 2D4C 6576 Level High.V-Lev0033D480 656C 2048 6967 6800 562D 4C65 7665 6C20 el High.V-Level0033D490 4C6F 7700 562D 4C65 7665 6C20 4C6F 7700 Low.V-Level Low.0033D4A0 562D 4C65 7665 6C20 4C6F 7700 562D 4C65 V-Level Low.V-Le0033D4B0 7665 6C20 4C6F 7700 562D 4C65 7665 6C20 vel Low.V-Level0033D4C0 4C6F 7700 562D 4C65 7665 6C20 4C6F 7700 Low.V-Level Low.0033D4D0 562D 4C65 7665 6C20 4C6F 7700 562D 4C65 V-Level Low.V-Le0033D4E0 7665 6C20 4C6F 7700 562D 4C65 7665 6C20 vel Low.V-Level0033D4F0 4C6F 7700 562D 4C65 7665 6C20 4C6F 7700 Low.V-Level Low.0033D500 562D 4C65 7665 6C20 4C6F 7700 562D 4C65 V-Level Low.V-Le0033D510 7665 6C20 4C6F 7700 562D 4C65 7665 6C20 vel Low.V-Level0033D520 4C6F 7700 4461 7461 2083 0044 6174 6120 Low.Data ƒ.Data0033D530 8300 4461 7461 2083 0044 6174 6120 8300 ƒ.Data ƒ.Data ƒ.0033D540 4461 7461 2083 0044 6174 6120 8300 4461 Data ƒ.Data ƒ.Da0033D550 7461 2083 0044 6174 6120 8300 4461 7461 ta ƒ.Data ƒ.Data0033D560 2083 0044 6174 6120 8300 4461 7461 2083 ƒ.Data ƒ.Data ƒ0033D570 0044 6174 6120 8300 4461 7461 2083 0052 .Data ƒ.Data ƒ.R0033D580 6973 6500 5269 7365 0052 6973 6500 5269 ise.Rise.Rise.RiSecond IC in dead.binCode:Offset(h) 00 02 04 06 08 0A 0C 0E0085B610 FFFF 01F0 FFFF 0290 FFFF 02D0 FFFF 02700085B620 FFFF 0250 FFFF 0110 FFFF 0230 FFFF 02B00085B630 FFFF 02B0 FFFF 05B0 FFFF 0510 FFFF 06700085B640 FFFF 0510 FFFF 0550 FFFF 0430 FFFF 05900085B650 FFFF 05D0 FFFF 04D0 FFFF 05F0 FFFF 03B00085B660 FFFF 04F0 FFFF 0510 FFFF 0470 FFFF 05F00085B670 FFFF 0410 FFFF 0710 FFFF 06D0 FFFF 06900085B680 BE6F 05F0 4242 0510 4146 0330 3032 01B00085B690 0055 03D0 0080 05F0 4E00 0550 9500 06D00085B6A0 20C1 06B0 B496 0530 20C1 0590 28D5 06F00085B6B0 D857 04B0 0053 03F0 5045 0490 3833 05B00085B6C0 4400 06B0 0084 06B0 4400 0550 0000 05300085B6D0 0000 06B0 00D5 0650 0967 0630 4000 05D00085B6E0 4001 0370 0100 05F0 0098 06D0 4000 05B00085B6F0 0101 05F0 0100 0350 0000 0570 1E00 05900085B700 0001 0690 00EA 05F0 0026 04B0 0103 04500085B710 0000 0370 FF10 0470 0016 04F0 0200 05900085B720 0000 0610 0000 0510 0005 0470 0909 05B00085B730 0901 05D0 00F8 04B0 FF08 0430 0012 0410https://www.mouser.com/datasheet/2/268/SST39VF6401B_SST39VF6402B_64_Mbit_x16_Multi_Purpos-709070.pdf(datasheet)

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 09, 2024, 05:50:46 pm
content: If the 39VF6401 was corrupted, i think the verification gave me an error while I was rewriting it as well.I'm thinking something went wrong during the firmware update rather than the 39VF6401 being faulty.It is indeed the upperROM where the corruption is concentrated. It seems to be split 2 bytes at a time into upperROM/lowerROM.I am attaching a dead.bin split into upper/lower.

author: fzabkar
author_rank: Super Contributor
timestamp: June 09, 2024, 06:12:32 pm
content: That's cleared up some confusion for me. I didn't realise that you had merged/interleaved the two dumps. Each chip is 16-bits wide, so they are being accessed in parallel via a 32-bit bus.

author: fzabkar
author_rank: Super Contributor
timestamp: June 09, 2024, 07:21:39 pm
content: I've been studying the Ruby.ldf firmware payload file.There are several DATA BLOCKs which are written to the address space at base offset 0x40000000. I believe this address corresponds to the flash ROMs.For example, the following data block is written to 0x40000080 and has a size of 0x1000 bytes. "4097" is the equivalent decimal count in bytes plus 1 checksum byte at the end.Code:Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F00008400 44 41 54 41 20 42 4C 4F 43 4B 0D 0A DATA BLOCK..00008410 2C 23 48 34 30 30 30 30 30 38 30 2C 23 48 31 30 ,#H40000080,#H1000008420 30 30 0D 0A 34 30 39 37 0D 0A 00..4097..In addition to these data blocks there are also several EXTENSION DATA blocks.The following example writes 0x200 bytes to address 0x44003c00. "1024" is the number of bytes that follow. There is no checksum. These bytes are not in binary format, but are the ASCII coded hex values.Code:EXTENSION DATA44003c00,200,1024The bulk of the EXTENSION DATA is written to 0x44000000 - 0x44003E6B.The final segment is written to 0xffff0400:Code:EXTENSION DATAffff0400,7,144C4954544C4500 <-- this is the data = "LITTLE<00>"If 0x44000000 is in RAM, then I guess that the EXTENSION DATA don't matter. It may be just auxiliary code that runs during the update.That would also explain the EXTENSION COMMAND TABLE:Code:EXTENSION COMMAND TABLECF:GO44001610EO:GO44001874FC:GO44001914PF:GO440019D4QF:GO44002900TI:GO44002A68FP:GO44002A9C

author: asis
author_rank: Frequent Contributor
timestamp: June 10, 2024, 10:10:19 am
content: Hi,Using the FW2Bin.exe utility, you could easily mislead yourself.In fact, early versions of FLK199x used the "A201" Flash memory module SST39VF800A_2pcs + CY62147V33_2pcs.They are combined in pairs and use a common address field, but the data field from each pair is distributed over 16 bytes, thereby covering the 32 bit data bus D-ASIC.Thus, the data is structured.Judging by your photos, the "tetra" concept remains the same.When you move the module itself (A1) from one scope to another, the functionality remains the same, but you must understand that you are also transferring the calibration constants.This suggests that somehow the SN is checked and its OTP mask matches only when you run the flasher to update the SW.A similar topic has already been discussed:https://www.eevblog.com/forum/testgear/fluke-192-196-199-fw-upgrade/

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 10, 2024, 02:00:20 pm
content: Are you saying that the serial number was written to the main SoC (D-ASIC) and for some reason it was corrupted?Isn't it just a simple test program written that is read when the flash ROM cannot be booted or when the ^> button is pressed?Naturally, if the A1 module (which is not present in the THS3024 and is mounted directly on the board) is moved to another one, both the serial and calibration constants will move.Of course, I understand that ROM and RAM, which exist in two pieces each, are 16bit+16bit=32bit.The problem is how to recover the part from $4EC0-$FFFF, which we believe has its serial number and calibration constants written to it.All I have is a FlashROM dump containing $4EC0-$FFFF which I believe is corrupted, and a bootable firmware ROM generated by fw2bin.exe.

author: asis
author_rank: Frequent Contributor
timestamp: June 10, 2024, 02:59:08 pm
content: It is unlikely that SN failed in OTP.I'm more inclined that the BGA simply fell off.But there is no need to rush here, leaving all these manipulations for later.BTW Flash dumps from your scope are very similar to FLK 190 series.I'm very interested in your work.Continue.

author: fzabkar
author_rank: Super Contributor
timestamp: June 10, 2024, 03:48:00 pm
content: Quote from: squadchannel on June 10, 2024, 02:00:20 pmThere 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:Offset(h) 00 02 04 06 08 0A 0C 0E00008000 FFFF 0200 FFFF 0000 FFFF 0000 FFFF DC0D00008010 FFFF 0044 FFFF 0000 FFFF 0000 FFFF 000000008020 FFFF 1348 FFFF 7011 FFFF 0100 FFFF 6900........0000A000 0004 FFFF C419 FFFF 0100 FFFF AF6C FFFF0000A010 7600 FFFF 0000 FFFF 0000 FFFF 0000 FFFF0000A020 0100 FFFF CE00 FFFF 2000 FFFF 5500 FFFF

author: coromonadalix
author_rank: Super Contributor
timestamp: June 10, 2024, 04:30:16 pm
content: can this 2014 FW and flash tool help ? attachedFirmware 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

author: fzabkar
author_rank: Super Contributor
timestamp: June 10, 2024, 08:34:22 pm
content: 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:,#H4020c000,#H1000,#H4020d000,#Hbc2,#H4020dbc4,#H1000This is the corresponding area in dead.bin:Code:Offset(h) 00 02 04 06 08 0A 0C 0E0020DBB0 0000 0000 0000 0000 0000 0000 0000 00000020DBC0 0000 FFFF 0000 4902 0000 0944 0000 0000^^^^0020DBD0 0000 0000 0000 0000 0000 0000 0000 0000Is 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?

author: fzabkar
author_rank: Super Contributor
timestamp: June 11, 2024, 04:34:14 pm
content: Ruby.ldfCode:,#H40000000,#H28,#H40000028,#H4,#H40000030,#H8,#H40000040,#H30,#H40000080,#H1000dead.binCode:Offset(h) 00 02 04 06 08 0A 0C 0E00000000 1122 3344 5566 7788 5555 5555 AAAA AAAA00000010 3333 3333 CCCC CCCC 0F0F 0F0F F0F0 F0F000000020 FF00 FF00 00FF 00FF 3000 0040 FFFF FFFF00000030 4000 0040 5800 0040 FFFF FFFF FFFF FFFF00000040 0080 0040 0040 0000 00C0 0040 0040 000000000050 0000 0000 0000 0000 0000 3F40 0040 000000000060 0040 3F40 0040 0000 0000 0000 0000 000000000070 0000 0000 0200 0000 0020 0000 0200 0000These words have not been reprogrammed by the update. Are they corrupt?Code:Offset(h) 00 02 04 06 08 0A 0C 0E00000020 FFFF FFFF00000030 FFFF FFFF FFFF FFFF........00000070 0000 0000 0200 0000 0020 0000 0200 0000

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 13, 2024, 07:03:22 am
content: omggggggggggggggggggggggggggggI 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.

author: coromonadalix
author_rank: Super Contributor
timestamp: June 13, 2024, 10:01:24 am
content: congratzand yes if you can tell us your latest recovery story ... to help others in the future

author: fzabkar
author_rank: Super Contributor
timestamp: June 13, 2024, 10:39:07 pm
content: 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

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 14, 2024, 04:43:38 pm
content: 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.binDrag 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 fromhttps://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 topichttps://www.eevblog.com/forum/microcontrollers/fluke-19xbcii-firmware-to-binary-converter/msg1280562Drag and drop "Ruby.ldf" or "Tetra.ldf" into "FlukeFW2Bin.exe" and run it.FlukeFW2Bin updateFile.ldfAfter 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-$FFFFThe 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.binDrag 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.

author: asis
author_rank: Frequent Contributor
timestamp: June 16, 2024, 11:41:15 am
content: 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!

author: squadchannel
author_rank: Frequent Contributor
timestamp: June 16, 2024, 02:06:19 pm
content: Quote from: asis on June 16, 2024, 11:41:15 amBUSHEALTH 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

author: patpat
author_rank: Contributor
timestamp: September 06, 2024, 01:08:54 am
content: Awesome job.To understand the memory map of these scopes I found useful the "Instrument Security Procedures" documentation fromhttps://www.fluke.com/en-us/support/instrument-securityI'm uploading here the ones for models:Fluke 192B, 196B, 199B, 192C, 196C, 199C, 215C, 225C&Fluke 190-062, 190-102, 190-104, 190-202,190-204, 190-502, 190-504 (Series II)These documents also say things like:QuoteOff course these commands are still undocumented but looking at the Fluke/Tektronix 190-204 Firmware Upgrade it could be one of:QuoteBest,Pat

author: feedback.loop
author_rank: Frequent Contributor
timestamp: November 27, 2024, 11:56:15 pm
content: Quote from: squadchannel on June 14, 2024, 04:43:38 pmThank you very much, squadchannel! This helped me to fix a Fluke 190-202 scopemeter.You call the chips upper and lower, which may be a bit misleading. I would call them according to low (least significant) and high (most significant) 16 bits of the 32-bit data bus. The upper in your terminology holds the low 2 bytes.How do you know about the checksums and XORs? I would love to understand how that should be done correctly.Even better would be to get Fluke flash utility, so we wouldn't have to desolder the chips.

author: fzabkar
author_rank: Super Contributor
timestamp: November 30, 2024, 03:02:24 am
content: Quote from: feedback.loop on November 27, 2024, 11:56:15 pmActually, I was the one who uncovered the checksum algorithms. Firstly, I noticed that there were several blocks of code which were damaged in such a way that they could be reconstructed by merging two halves. I had already written a tool for this purpose.Next I noticed that each block had a lonely byte at the end, and this led me to suspect that these were checksum bytes. I then ran my CHECKSUM.EXE tool against these blocks. This tool tests a block of data using several checksum algorithms. It found a simple 8-bit sum plus an 8-bit XOR. You should find these tools attached to one or more of my posts.If you have any blocks of code or data with an unknown checksum, I'll see if I can help you locate it. It would probably be best to start your own thread, though.

author: squadchannel
author_rank: Frequent Contributor
timestamp: November 30, 2024, 03:18:51 am
content: Yes, thanks to fzabkar.currently coding a utility tool for Scopemeter. It will take some time yet.

author: asis
author_rank: Frequent Contributor
timestamp: November 30, 2024, 09:48:06 pm
content: Hi,You call the chips upper and lower, which may be a bit misleading. I would call them according to low (least significant) and high (most significant) 16 bits of the 32-bit data bus. The upper in your terminology holds the low 2 bytes.@feedback.loopThe error was made in document 190BC___mveng0000.I offer my representation of the A201 module circuit.-The circuit is very similar to the THS3024.

author: kisobran
author_rank: Newbie
timestamp: May 10, 2025, 05:20:42 pm
content: Hello,could someone please tell me if Battery vor Fluke190-204 and Tektronix THS3024 are interchangeable?Could I put the Battery from THS3024 into Fuke190-204?Thank you and best regards

author: rvalente
author_rank: Frequent Contributor
timestamp: September 28, 2025, 06:26:18 pm
content: So after seeing this topic I've bought a 190-502 for around 300 bucks (which is a bargain here, a brand new is around 10KUSD). My unit looks very very clean, not board repair attempts and a behavior very similar to the previous here...So firmware dumping time?The display film is damaged(heat?). I believe it has been replaced, this unit served as a donor parts. Does anyone know a similar display? Searching for codes on Ali is prohibiting expensive.

author: squadchannel
author_rank: Frequent Contributor
timestamp: September 29, 2025, 12:29:04 am
content: LCD is KCG060QVLAA. CSTN, 8-bit.but, there is no datasheet, and resolution appears to be 320x240 (4:3), the display area's aspect ratio is not 4:3. in other words, the dot size is not square.it is very difficult to find. need to obtain the exact same LCD.attached the dump tool.change the serial port in the .cfg file to match your computer.Press and hold the top and right buttons on the keypad the press the power button to enter DFU mode (UHM mode). it heard weak beep.Then drag and drop the .cfg file onto scmtool.exe.

author: rvalente
author_rank: Frequent Contributor
timestamp: September 30, 2025, 06:24:39 pm
content: Quote from: squadchannel on September 29, 2025, 12:29:04 amTks by the software, attached are the dumps, it took a few times to finish, it would freeze on ffff73, ffff7e...etc, but after a few tries it came.The memory looks totally corrupted, no calibration data.As I've read on other posts I believe it is possible to flash with your tool, but I do not know how. Can you please guide me?https://www.eevblog.com/forum/testgear/fluketektronix-bushealth-code-192c196c199c215c225c190-(i-ii)-ths3000/?allhttps://www.eevblog.com/forum/repair/fluke-199c-scopemeter-repair/?all

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 01, 2025, 12:12:49 am
content: I checked the dump data. It appears it's not reading properly from the scope.This is a known issue. after the scope boots normally, executing a specific command to enter UHM mode allows it to read correctly.However, since it currently won't boot, I'll look for a solution.The quickest fix is to desolder it, but do you have the equipment? You'll need a programmer that supports the SST39VF6401B.

author: rvalente
author_rank: Frequent Contributor
timestamp: October 01, 2025, 12:22:42 am
content: Hi, I really appreciate you help, tks a lot!Yes, I do, I've soldering equipment, TL866 and waiting for the TSOP48 adapter to arrive from Ali.Im scratching my head trying to understand the proper steps to use the various tools the fellows from this and other topics have made.I mean, to get the firmware from Fluke Update SW, decrypt it, slice in two flashes and program it.If my calibration is totally lost, I may send the scope for Fluke Service for calibration, wonder if they can cal everything or if some "factory cal" is required.About the dump on UHM mode, if it finishes, the data is consistently always the same, so I believe the memory is really corrupted.Is it possible to use your tool to flash from .bin to the scope? Well, I may loose the cal data if its not reading properly.Well, Im open to try a few options

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 01, 2025, 01:05:54 am
content: it can flashing to it too. tested it by my 3024.Theencryptedfirmware used by the updater has beendecryptedby@patpat.https://www.eevblog.com/forum/microcontrollers/fluke-19xbcii-firmware-to-binary-converterWhether calibration can be restored depends on the binary. It might be recoverable at the last minute, like in my case.Quote from: rvalente on October 01, 2025, 12:22:42 amThat's incorrect. when reading corrupted data, it doesn't looks like this. This is a known issue: after the scope boots normally, executing a specific command (EM) causes the flash to map to $40000000.

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 01, 2025, 01:42:36 am
content: I got it. needed a magic word.try using this config.dont forget to change the port.PS:If possible, could you take a close-up photo board top and back of the inside of the shield on the attenuator section of the scope input (not meter)?

author: rvalente
author_rank: Frequent Contributor
timestamp: October 01, 2025, 05:31:02 pm
content: Uow! Very nice work mate, the dump came out good this time with the calibration data!Also, I noticed the byte counter runs more smoothly now, all the reads came up good from the first try.I'll send the requested pictures soon, my cellphone camera is kinda bad for macros.Can you please guide me for the next steps to load a good firmware?

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 01, 2025, 08:07:03 pm
content: after operating the keypad, execute it.Do not forget to change the port.Tested in my 3024, valid firmware and calibration.PS:difference from the dumped firmware isn't significant, it might not be a firmware issue. anyway, try it.

author: rvalente
author_rank: Frequent Contributor
timestamp: October 01, 2025, 08:40:04 pm
content: Some board pictures, my cellphone has a below average camera.Let me know if you need more specifics

author: rvalente
author_rank: Frequent Contributor
timestamp: October 01, 2025, 09:47:35 pm
content: Quote from: squadchannel on October 01, 2025, 08:07:03 pmTks a lot by your effortBut dang, unlucky me!Yes on flash erase, but still blank screen + bip and loops! Tried twiceA lot of other things could be wrong, wonder what. Bad ram? Bad Flash chips?

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 02, 2025, 01:49:04 am
content: Did it finish without errors?It writes the calibration area at the end and finishes. 8000-FFFFdump it and compare to see if the write was successful.since the entire area takes time, just the firmware part.attached.Thanks for the photo. might help show the difference from the 500MHz model.

author: rvalente
author_rank: Frequent Contributor
timestamp: October 02, 2025, 01:34:22 pm
content: Quote from: squadchannel on October 02, 2025, 01:49:04 amHello, yes It did finish without errors. Attached the cmd output while flashing, looks fine to me.I've read flash dump twice after power cycling, the contents matches between them matches. Also, I re flashed and read dump before power cycling, it matches with the both previous read after power cycle.The read dumps diverges a lot from the .bin you've provided. Maybe bad flash chips?Tks once again for you help!

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 02, 2025, 01:54:24 pm
content: That part will still function even if it's different.0x38-0x3F has not been written. it remains at its erased default value of FF.0x2C-0x2F has also not been written, so it should be FF, but it may have been rewritten by the firmware upon startup or the instant the power button was pressed.one location, 0x28 should be 30, not 54. it works even after changing it, try it?I know that firmware works on my THS3024. the issue might be with the hardware.PS:checked the board photos closely, and the front-end chip (C-ASIC) is different.I don't know if this was made to replace the old Philips OQ0260 C-ASIC or if it's a completely new designed part to support 500MHz.What I do know is that while rvaluette's 190-502 500MHz firmware does run, waveforms are not acquired correctly.

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 02, 2025, 02:18:28 pm
content: I tested the firmware dumped before rewriting it.https://www.eevblog.com/forum/repair/looking-for-firmware-dump-for-tek-ths3024/msg6055337/#msg6055337It functions normally.The problem is definitely hardware-related.Microcontroller (Spider) should be good.P-ASIC (PIC24) controlling the DC-DC power supply is also good.SRAM(2x CY62157EV30LL and CY62146EV30LL) is suspect.also, S-ASIC (the BGA one) is suspect. if this one is broken, it's the worst-case scenario!SRAM can be tested using the EX10 command within UHM mode, but it is useless unless the address where the SRAM is mapped is known.Code:EX10,#H(address),#H(size)ex)EX10,#H20400000,#H80000return0: good SRAM1: syntax error6: bad SRAM

author: rvalente
author_rank: Frequent Contributor
timestamp: October 02, 2025, 08:07:05 pm
content: Hello,I re-flashed again, but instead of "yes" on flash erase, I chose "skip", the 0x28 hold, but a very big chunk on 0x9368 is missing.I found the CY62157EV30LL on local broker, cypress genuine, but not the CY62146EV30LL. Only on Aliexpress (doubtful source), mouser/Digikey/Farnell are last resources due to extreme taxation from gov.What would you pursuit? I could replace the CY62157EV30LL easily.

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 03, 2025, 02:37:30 am
content: Quote from: rvalente on October 02, 2025, 08:07:05 pmif skip the erase, data will be completely invalid.because the write process performs an AND operation between the current flash contents and the data being written.After erasing, the contents are FF, so it doesn't affect the result. but skipping the erase, the data will be completely invalid.I'm thinking that if i remove the SRAM and pin the data pins to FF(or unique), might be able to find the memory location.

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 03, 2025, 08:44:50 am
content: 2x CY62157EV30LL is probably, but definitely 0x44000000. This is where it's used for updates.Code:EX12,#H44000000,#H100000CY62146EV30LL is probably 0x20400000. Spider Micro is also used Fluke 123,124. memory location from 123 SM. this is likely the spot.Code:EX11,#H20400000,#H80000after entering UHM mode via key operation, connect via serial terminal at 9600, 8N1. Enter multiple "X"(uppercase, no Enter). It should respond with "0" after 11 characters.then, try executing the two commands above.CY62157EV30LL requires a magic word.Code:WW10000000,4,0002000200020002after that.may want to enable "Implicit LF in every CR" and local echo.

author: rvalente
author_rank: Frequent Contributor
timestamp: October 07, 2025, 11:11:45 pm
content: Hello Mate,the CY62157EV30LL arrived today, but my hot air rework station ruptured the diaphragm. Once I replace the ram Ill let you know. Tks a lot by your help

author: asis
author_rank: Frequent Contributor
timestamp: October 08, 2025, 01:12:05 am
content: Hi,@rvalenteIf I were you, I'd take advantage of the opportunity to use the lamellas of the intended 80-pin connector (to the right of the D-ASIC BGA).And before desoldering the chips, I'd draw a diagram to help you determine your next steps.The lamellas were probably intended for installing a connector, as in the Fluke 199C (Module A201).All address, strobe, and data lines are grouped.The single CY62146EV30-LL-45Z5XI chip is likely video RAM for servicing the LCD.-All manipulations related to the EM are best (must be) performed with the AC power adapter connected.-Judging by the dump, the SCOPE you have was exhibited at some presentation and then went up for auction.

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 08, 2025, 06:04:59 pm
content: Quote from: asis on October 08, 2025, 01:12:05 amyes, it is VRAM. when removed, the device will boot up, but the display will not function properly.Quote from: asis on October 08, 2025, 01:12:05 amI know there's a demo mode (time-limited mode), but it can identify from the dump? How?

author: rvalente
author_rank: Frequent Contributor
timestamp: October 08, 2025, 07:42:06 pm
content: Quote from: asis on October 08, 2025, 01:12:05 amThats a good idea, Ill start of by checking the pinout from the available schematics from the 199C and trace this out. This is fun and I know how to do it, not like this embedded hacking that you guys are such pros!I asked the seller about my unit source: "He told me it came from a recycling company, about 4 years ago and it was working fine. It was for sale, in this time period no one showed interest to buy it. Recently he turned on to test it, it initialized and after a few seconds the screen started to boot loop and no image, just white blank."

author: asis
author_rank: Frequent Contributor
timestamp: October 09, 2025, 02:49:04 am
content: ...addresses where the strange phrase appears, and with multiple language support....

author: rvalente
author_rank: Frequent Contributor
timestamp: October 09, 2025, 10:55:14 am
content: Now we are sure this unit was diverted from its final source, recycling

author: squadchannel
author_rank: Frequent Contributor
timestamp: October 09, 2025, 11:09:34 am
content: Quote from: asis on October 09, 2025, 02:49:04 amIt's just a constant, it should be possible to enable it depending on the settings. it's somewhere in the calibration area. I'm not going to look for it.I've confirmed that firmware works. It didn't display any messages like "demo" or “return to Fluke.”Some languages were grayed out in the language settings, but it can remove by entering the command.