Products > Test Equipment
Tektronix TDS1000B and TDS2000B series hacks
harm:
Hi,
Any more news for TDS1000-2000 series hacks?
I've a TDS1002 scope with broken (monochrome) display. I want to replace/install color display. Will it work without 'hacking' the TDS1002 scope to TDS2002 and only wire the color display the right way (18pin mainboard to 15-pin display connector)?
Anyone done this before?
tautech:
--- Quote from: dav on May 15, 2016, 10:10:19 am ---If you should find how to entering the engineering mode, please post it on the forum! ;)
--- End quote ---
In this new thread:
https://www.eevblog.com/forum/testgear/tds-1000-2000-3000-bw-hack/
braikin:
The process in that thread didn't work for me (TDS2004B), but I was inspired to try looking at the firmware myself. Here's some of what I found, that might help people still stumbling upon this thread.
1. The model id is stored at the end Flash ROM along side the calibration data. Here's a bit of python which would patch the ROM if you're willing to desolder and re-program it. Based on observations others have made about the hardware, and the way the code branches based on model number, this will probably work. I used a TL866 to read the rom, but haven't tried programming (see #2).
with open('ROM.BIN', 'rb+') as patchedfw:
# Model IDs
#
# 0x0B = TDS2022B
# 0x0C = TDS2024B
# 0x0D = TDS2002B
# 0x0E = TDS2012B
# 0x0F = TDS2014B
# 0x10 = TDS2022B 1GS/s
# 0x11 = TDS1002B
# 0x12 = TDS1012B
# 0x13 = TDS1001B
# 0x14 = TDS2004B
patchedfw.seek(0x7f0007)
# Update model per list above.
patchedfw.write(bytearray([0xf]))
# Update Checksum
patchedfw.seek(0x7f0004)
data = patchedfw.read(0x9f2)
bytes = [ord(b) for b in data]
csum = pack(">I", sum(bytes))
patchedfw.seek(0x7f0000)
patchedfw.write(bytearray(csum))
The address references above are the physical addresses in ROM. They're mapped differently by FPGA in firmware. If you want to peek/poke from service menu, nvram starts at 0x002f0000.
2. Looking at the code, upgrading from any sample rate to another (e.g. 1GS/s to 2GS/s) will definitely result in an uncalibrated scope. Address 0x42b340 is start method which loads cal data. The very first branch in the method matches 2GS/s models and expects the cal data to be a few bytes longer.
I don't have the capability to fix cal, so I'll probably abandon further research like finding a way to do this which doesn't require ROM removed.
braikin:
Cal issue is resolved, I'll patch my ROM. If I don't break anything soldering, I'll report back what happens in a couple days.
Cal data was organized into blocks. I had a thought autocal probably manages some of these blocks too:
[factory addr=0x7f0000 sz=2546 csum=0x48242,
spc addr=0x7d652c sz=1564 csum=0x1bc53,
trig_fpc addr=0x7d0000 sz=396 csum=0x11750,
fiso_fpc addr=0x7d01c2 sz=11088 csum=0x15232b,
fiso_fpc_peak_detect_5US addr=0x7c0000 sz=11088 csum=0x14bae7,
fiso_fpc_peak_detect_10US addr=0x7c2b8e sz=11088 csum=0x16344a,
fiso_fpc_peak_detect_25US addr=0x7c571c sz=11088 csum=0x158a91,
fiso_fpc_peak_detect_50US addr=0x7c82aa sz=11088 csum=0x160cb1,
fiso_fpc_peak_detect_100US addr=0x7cae38 sz=11088 csum=0x15a601,
fiso_ch1_sample_offset addr=0x7d3d54 sz=2673 csum=0x1e307,
fiso_ch2_sample_offset addr=0x7d493e sz=2673 csum=0x105c,
fiso_ch1_pkdet_offset addr=0x7d2d50 sz=1980 csum=0x3d7d1,
fiso_ch2_pkdet_offset addr=0x7d3552 sz=1980 csum=0x325,
fiso_ch1_pkdet_lkup_corr addr=0x7d5528 sz=1980 csum=0x3dc38,
fiso_ch2_pkdet_lkup_corr addr=0x7d5d2a sz=1980 csum=0x3d71a,
trig_fpc_2 addr=0x7e0000 sz=396 csum=0x12bd9,
fiso_fpc_2 addr=0x7e01c2 sz=11088 csum=0x129b8a,
fiso_fpc_2_peak_detect_5US addr=0x7d6d60 sz=11088 csum=0x132c93,
fiso_fpc_2_peak_detect_10US addr=0x7d98ee sz=11088 csum=0x13408d,
fiso_fpc_2_peak_detect_25US addr=0x7dc47c sz=11088 csum=0x132590,
fiso_fpc_2_peak_detect_50US addr=0x7e6590 sz=11088 csum=0x1307bf,
fiso_fpc_2_peak_detect_100US addr=0x7e911e sz=11088 csum=0x12e5b2,
fiso_ch3_sample_offset addr=0x7e3d54 sz=2673 csum=0x47bef,
fiso_ch4_sample_offset addr=0x7e493e sz=2673 csum=0xf97,
fiso_ch3_pkdet_offset addr=0x7e2d50 sz=1980 csum=0x9e6d,
fiso_ch4_pkdet_offset addr=0x7e3552 sz=1980 csum=0x184af,
fiso_ch3_pkdet_lkup_corr addr=0x7e5528 sz=1980 csum=0x3d78f,
fiso_ch4_pkdet_lkup_corr addr=0x7e5d2a sz=1980 csum=0x3f20e]
The 4 sections who's size change when upgrading to 2GS/s are `fiso_ch?_sample_offset`. I did an auto cal, and observed checksum changed for those.
braikin:
Success!?
Software identifies as a TDS2024B everywhere I could think to check. I think I see more HF noise. FFT modes at 2GS/s work. 2.5ns/div works. If there's a test you'd like me to try, and I have the equipment, I don't mind giving it a try.
Obviously desoldering the the ROM isn't the easiest solution, but if you'd like to try it:
* Update to the latest firmware. V22.16. This may not be required, but this is the version I reverse engineered. Earlier firmware may or may not work.
* Desolder the ROM, dump its contents to a binary file.
* Keep a backup of the ROM file. If something goes wrong, you can only restore your unit to old firmware if you have a copy.
* Download the attached patch.py.
* If you're patching a 2ch model, change rom.write(bytearray([0x0c])) to rom.write(bytearray([0x0b])).
* Don't try to patch to an impossible configuration. You'll be left with a brick and required remove ROM and retry. Don't use a model with a different number of channels, don't user a model with a color display if you have black-white. If you make a mistake, the scope won't boot.
* Use patch.py to update your firmware, then reprogram.
* When you boot up the first time, Auto Calibration self test will fail. This isn't a problem. Just Auto Cal the scope, then cycle power.
* You're done.
Tips:
* Save a backup of old ROM, so you can rollback if needed.
* Three LEDs in upper left should light up as soon as you power on scope. If they don't maybe ROM isn't soldered well.
* If you've flashed an incompatible model number, you'll get stuck at the 3 LEDs.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version