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

[squadchannel]

update 15/06/2024: Problem solved.
https://www.eevblog.com/forum/repair/looking-for-firmware-dump-for-tek-ths3024/msg5542145/#msg5542145

I 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/msg1280562

I 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.

[fzabkar]

Can you upload the dump and the regenerated flash image? Perhaps someone may know how to edit the missing data.

[squadchannel]

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".

[squadchannel]

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):

[fzabkar]

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: [Select]

Offset(h) 00       04       08       0C

0000FFF0  FFFFFFFF FFFFFFFF 9B000000 71FFFFFF

Edit:

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: [Select]

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

00000000  FFFF 0200 FFFF 0000 FFFF 0000 FFFF DC0D   0x8000_9FFF.bin

00000000  0004 FFFF C419 FFFF 0100 FFFF AF6C FFFF   0xA000_BFFF.bin

00000000  0004 0200 C419 0000 0100 0000 D86B 210E   0xC000_DFFF.bin

00000000  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF   0xE000_FFFF.bin

[fzabkar]

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).

[fzabkar]

The 8KiB block at 0xC000 has corruption in this area:

Code: [Select]

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

0000D270            FFFF 6614 FFFF 0100 FFFF 0000
0000D280  0000 6714 0C00 0100 0A00 0000 FFFF 6814
0000D290  FFFF 0100 FFFF 0000 FFFF 6914 FFFF 0100
........
0000D9A0  FFFF 0062 FFFF 0200 FFFF 0000 FFFF D908
0000D9B0  FFFF 0040 FFFF 1202 FFFF 0300 FFFF 0000
0000D9C0  FFFF 0000

If 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: [Select]

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

0000DFF0  FFFF FFFF FFFF FFFF 9B00 0000 71FF FFFF

I 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.

[squadchannel]

The 8KiB block at 0xC000 has corruption in this area:

Code: [Select]

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

0000D270            FFFF 6614 FFFF 0100 FFFF 0000
0000D280  0000 6714 0C00 0100 0A00 0000 FFFF 6814
0000D290  FFFF 0100 FFFF 0000 FFFF 6914 FFFF 0100
........
0000D9A0  FFFF 0062 FFFF 0200 FFFF 0000 FFFF D908
0000D9B0  FFFF 0040 FFFF 1202 FFFF 0300 FFFF 0000
0000D9C0  FFFF 0000

If 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: [Select]

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

0000DFF0  FFFF FFFF FFFF FFFF 9B00 0000 71FF FFFF

I have attached my checksum calculator and bitwise AND-ing tool.

I 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.

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).

The 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.

[squadchannel]

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....

[fzabkar]

I will test the $6700 & $8000x4 block copy when I wake up in the morning. I hope it works....

I 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.

[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]

The binaries in the area starting with $6700 have binaries similar to $4700. We believe this is probably the binary recognized as THS3014.

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]

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.

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.

The binaries in the area starting with $6700 have binaries similar to $4700. We believe this is probably the binary recognized as THS3014.

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.

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.

[fzabkar]

What is the part number of the two flash chips?

[squadchannel]

What is the part number of the two flash chips?

SST39VF6401B

[squadchannel]

I found an interesting entry in the datasheet.
Perhaps a security ID is set? I'll check it out.

Security ID
The SST39VF640xB devices offer a 256-bit Security ID space. The Secure ID space is divided into
two 128-bit segments: one factory-programmed segment and one user-programmed segment. The
first segment is programmed and locked at Microchip with a random 128-bit number. The user
segment is left unprogrammed for the customer to program as desired.
To program the user segment of the Security ID, the user must use the Security ID Word-Program
command. To detect end-of-write for the SEC ID, read the toggle bits. Do not use Data# Polling. Once
this is complete, the Sec ID should be locked using the User Sec ID Program Lock-Out. This disables
any future corruption of this space. Note that regardless of whether or not the Sec ID is locked, neither
Sec ID segment can be erased.
The Secure ID space can be queried by executing a 3-byte command sequence with Enter Sec ID
command (88H) at address 555H in the last byte sequence. To exit this mode, the Exit Sec ID
command should be executed. Refer to Table 6 for more details.

[fzabkar]

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.bin

Code: [Select]

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

0033D440  454E 4869 4500 0056 4E41 6576 0052 2048  ENHiE..VNAev.R H
0033D450  414D 6800 5245 4C65 4D45 6C20 454E 6768  AMh.RELeMEl ENgh
0033D460  4500 2D4C 4E41 656C 0044 6967 4554 562D  E.-LNAel.DigETV-
0033D470  4445 7665 5445 4869 454C 0056 4500 6576  DEveTEHiEL.VE.ev
0033D480  4C45 2048 0044 6800 4554 4C65 4445 6C20  LE H.Dh.ETLeDEl 
0033D490  5445 7700 454C 4C65 4500 6C20 4C45 7700  TEw.ELLeE.l LEw.
0033D4A0  0044 4C65 4554 6C20 4445 7700 5445 4C65  .DLeETl DEw.TELe
0033D4B0  454C 6C20 4500 7700 4C45 4C65 0044 6C20  ELl E.w.LELe.Dl 
0033D4C0  4554 7700 0000 4C65 0000 6C20 0000 7700  ETw...Le..l ..w.
0033D4D0  0000 4C65 0000 6C20 0000 7700 0000 4C65  ..Le..l ..w...Le
0033D4E0  0000 6C20 0000 7700 0000 4C65 0000 6C20  ..l ..w...Le..l 
0033D4F0  0000 7700 0000 4C65 0000 6C20 0000 7700  ..w...Le..l ..w.
0033D500  0000 4C65 004C 6C20 656C 7700 4C65 4C65  ..Le.Ll elw.LeLe
0033D510  6C3A 6C20 6576 7700 3A00 4C65 7665 6C20  l:l evw.:.Level 
0033D520  004C 7700 656C 7461 4C65 0044 6C3A 6120  .Lw.eltaLe.Dl:a 
0033D530  6576 4461 3A00 2083 7665 6174 004C 8300  evDa:. ƒveat.Lƒ.
0033D540  656C 7461 4C65 0044 6C3A 6120 6576 4461  eltaLe.Dl:a evDa
0033D550  3A00 2083 7665 6174 004C 8300 656C 7461  :. ƒveat.Lƒ.elta
0033D560  5374 0044 7573 6120 5374 4461 7573 2083  St.Dusa StDaus ƒ
0033D570  5374 6174 7573 8300 5374 7461 7573 0052  Statusƒ.Sttaus.R
0033D580  5374 6500 7573 7365 5374 6973 7573 5269  Ste.usseStisusRi

generated.bin

Code: [Select]

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

0033D440  6C20 4869 6768 0056 2D4C 6576 656C 2048  l High.V-Level H
0033D450  6967 6800 562D 4C65 7665 6C20 4869 6768  igh.V-Level High
0033D460  0056 2D4C 6576 656C 2048 6967 6800 562D  .V-Level High.V-
0033D470  4C65 7665 6C20 4869 6768 0056 2D4C 6576  Level High.V-Lev
0033D480  656C 2048 6967 6800 562D 4C65 7665 6C20  el High.V-Level 
0033D490  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-Le
0033D4B0  7665 6C20 4C6F 7700 562D 4C65 7665 6C20  vel Low.V-Level 
0033D4C0  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-Le
0033D4E0  7665 6C20 4C6F 7700 562D 4C65 7665 6C20  vel Low.V-Level 
0033D4F0  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-Le
0033D510  7665 6C20 4C6F 7700 562D 4C65 7665 6C20  vel Low.V-Level 
0033D520  4C6F 7700 4461 7461 2083 0044 6174 6120  Low.Data ƒ.Data 
0033D530  8300 4461 7461 2083 0044 6174 6120 8300  ƒ.Data ƒ.Data ƒ.
0033D540  4461 7461 2083 0044 6174 6120 8300 4461  Data ƒ.Data ƒ.Da
0033D550  7461 2083 0044 6174 6120 8300 4461 7461  ta ƒ.Data ƒ.Data
0033D560  2083 0044 6174 6120 8300 4461 7461 2083   ƒ.Data ƒ.Data ƒ
0033D570  0044 6174 6120 8300 4461 7461 2083 0052  .Data ƒ.Data ƒ.R
0033D580  6973 6500 5269 7365 0052 6973 6500 5269  ise.Rise.Rise.Ri

Second IC in dead.bin

Code: [Select]

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

0085B610  FFFF 01F0 FFFF 0290 FFFF 02D0 FFFF 0270
0085B620  FFFF 0250 FFFF 0110 FFFF 0230 FFFF 02B0
0085B630  FFFF 02B0 FFFF 05B0 FFFF 0510 FFFF 0670
0085B640  FFFF 0510 FFFF 0550 FFFF 0430 FFFF 0590
0085B650  FFFF 05D0 FFFF 04D0 FFFF 05F0 FFFF 03B0
0085B660  FFFF 04F0 FFFF 0510 FFFF 0470 FFFF 05F0
0085B670  FFFF 0410 FFFF 0710 FFFF 06D0 FFFF 0690
0085B680  BE6F 05F0 4242 0510 4146 0330 3032 01B0
0085B690  0055 03D0 0080 05F0 4E00 0550 9500 06D0
0085B6A0  20C1 06B0 B496 0530 20C1 0590 28D5 06F0
0085B6B0  D857 04B0 0053 03F0 5045 0490 3833 05B0
0085B6C0  4400 06B0 0084 06B0 4400 0550 0000 0530
0085B6D0  0000 06B0 00D5 0650 0967 0630 4000 05D0
0085B6E0  4001 0370 0100 05F0 0098 06D0 4000 05B0
0085B6F0  0101 05F0 0100 0350 0000 0570 1E00 0590
0085B700  0001 0690 00EA 05F0 0026 04B0 0103 0450
0085B710  0000 0370 FF10 0470 0016 04F0 0200 0590
0085B720  0000 0610 0000 0510 0005 0470 0909 05B0
0085B730  0901 05D0 00F8 04B0 FF08 0430 0012 0410

https://www.mouser.com/datasheet/2/268/SST39VF6401B_SST39VF6402B_64_Mbit_x16_Multi_Purpos-709070.pdf (datasheet)

[squadchannel]

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.

[fzabkar]

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.

[fzabkar]

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: [Select]

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00008400              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,#H10
00008420  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: [Select]

EXTENSION DATA
44003c00,200,
1024

The bulk of the EXTENSION DATA is written to 0x44000000 - 0x44003E6B.

The final segment is written to 0xffff0400:

Code: [Select]

EXTENSION DATA
ffff0400,7,
14
4C4954544C4500  <-- 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: [Select]

EXTENSION COMMAND TABLE
CF:GO44001610
EO:GO44001874
FC:GO44001914
PF:GO440019D4
QF:GO44002900
TI:GO44002A68
FP:GO44002A9C

[asis]

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/

[squadchannel]

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.

[asis]

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.