| Electronics > Repair |
| [Solved!]Looking for firmware dump for Tek THS3024.(How to repair firmware) |
| << < (5/8) > >> |
| 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: ---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.. --- End code --- 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 DATA 44003c00,200, 1024 --- End code --- The bulk of the EXTENSION DATA is written to 0x44000000 - 0x44003E6B. The final segment is written to 0xffff0400: --- Code: ---EXTENSION DATA ffff0400,7, 14 4C4954544C4500 <-- this is the data = "LITTLE<00>" --- End code --- 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 TABLE CF:GO44001610 EO:GO44001874 FC:GO44001914 PF:GO440019D4 QF:GO44002900 TI:GO44002A68 FP:GO44002A9C --- End code --- |
| 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |