-
Full disclosure: I used AI for this.
2 months ago, I bought a barebones TDS3052 at an auction. I obviously wanted to enable all features but I didn't want to buy or make an I2C dongle, so I tried to patch the firmware instead. I created new floppy images and... bricked my scope.
If I was really going to modify the scope firmware, I'd need a TDS3000(B) simulator. Many days later, this was the result:
It simulated very slow at first, but I added a bunch of acceleration hacks that makes the simulator usable for interactive testing.
Once that was in place, I started adding features. This evening, I finally soldered a cable together that allowed me to unbrick the scope with BDM.exe. And then I installed the patched firmware. This is the result:
The video shows the following:- Revision number patched from v3.41 to v3.41p1.
- Ability to enable software options individually (no I2C dongles required, of course)
- Tetris! I need to tune the playing speed.
- Displaying a photo of the Tektronix development team. This picture was in the flash all along, but there was no way to show it. I looked hard for secret combinations to trigger it, but couldn't find any.
- Ability to switch the model number. Mine was a TDS3052 out of the box, so there's no point, but this is definitely useful for those with a TDS301x or TDS303x.
I had to remove Russian language support to free up RAM and flash storage. Uncompressed, the Russian language assets are 45KB larger than all the others, so this was at least one very good reason.
I'm thinking about more features to add. High on the list would be a way to dump the calibration data from the flash and NVRAM contents to floppy. And Tetris definitely also needs a way to retain the high score...
-
Wow!
Could you maybe add as feature:
* When booting, check DS1742W battery status and RTC running flags, and if battery is empty then overwrite the NVRAM with something that boots up with default settings. Say default to Jan 1 2000, 00:00, 10000 hours engine hours, all channels on at 1V/div, 10x voltage probe, DC, 1 us/div, MAC random last 3 bytes.
Or maybe store some of those setting in flash instead of NVRAM.
This so that the dead RTC battery no longer makes the scope useless.
-
And Tetris definitely also needs a way to retain the high score...
I would free more packages just for that!
-
How about a “wizard” for the screensaver feature?
-
This so that the dead RTC battery no longer makes the scope useless.
Yes.
So far, I’ve only been patching the main application, not the initial boot loader in sector 0. After running BDM last night, my battery status shows as almost depleted or something, so I will need to address this situation soon enough one way or the other. The flash write routines right now explicitly block the SW from overwriting sector 0 (boot) and 7 (calib data), which is one thing that will need to be addressed.
Just an info screen with battery status would be useful too.
It really makes no sense that the scopes croaks on a dead battery.
-
How about a “wizard” for the screensaver feature?
That’s why I asked. On the list! -
as a 1st will you share only the std FW with patched option, and after the added bonusses ?
+1 with reply #1 a dead battery is a nightmare -
as a 1st will you share only the std FW with patched option, and after the added bonusses ?
Sorry, I don’t understand what you mean? -
* When booting, check DS1742W battery status and RTC running flags, and if battery is empty then overwrite the NVRAM with something that boots up with default settings. Say default to Jan 1 2000, 00:00, 10000 hours engine hours, all channels on at 1V/div, 10x voltage probe, DC, 1 us/div, MAC random last 3 bytes.
Or maybe store some of those setting in flash instead of NVRAM.
Sicco,
Attached is flash_rom_4mb_nvsram_guard_sw_options_on_p1.bin.zip.
It does the following:- Enable all software options permanently.
- Extensive checking for NVSRAM corruption. Uses sensible default values. Stores MAC in flash.
- Version v3.41p1. Marked as Unofficial/Experimental
- Russian language pack removed to free up code space
Scope doesn't boot
Some data in the NVSRAM has checksums, some does not. Some data is compressed with LZSS, other is not. The scope doesn't always hang when data is corrupt, it does that for the following scenario: it first decompresses data to a decompression buffer and then does the checksum. When the data is corrupt, it's possible that the decompressed data exceeds the size of the buffer. This will overwrite code and/or data in the SDRAM and bad things happen. Dumb...
The new firmware guards against that.
Ethernet MAC is now stored in the flash
For model B scopes, NVSRAM contains the MAC. With the new FW, the scope will always copy the MAC to a location in the application storage part of the flash. After that, it will always use the App Flash MAC instead of the NVSRAM version. If the scope boots, the NVSRAM is corrupt and there's no App Flash MAC, then a random MAC will be generated. (Only the bottom 3 bytes, the 3 top bytes are fixed at the Tektronix MAC.)
For non-B scopes, all MAC logic is ignored. When a TDS3EM card is inserted, the scope gets the MAC from the card, not from NVSRAM.
IMPORTANT: if you refresh firmware, the App Flash section gets erased and the MAC with it. I don't think this is a major issue...
The attached image has calibration data of my scope!!!
Before testing, you need to merge your flash calibration data with the attached image.
Use BDM.exe to dump the flash_target_scope_original.bin. Then run this command (Unix/macOS/mingW):Code: [Select]cp flash_tom_patched.bin flash_target_scope_patched.bin &&
dd if=flash_target_scope_original.bin of=flash_target_scope_patched.bin \
bs=131072 skip=20 seek=20 count=12 conv=notrunc
This creates flash_target_scope_patched.bin. Bytes 0x0 to 0x27FFFF come from the attached bin file. Section 0x280000 to 0x3FFFFF comes from the target scope bin file. That section contains calibration data, the scope model number etc.
Needs more testing.
I did extensive testing on the simulator for a TDS3052 and TDS3052B and on the actual TDS3052 hardware, but I don't have B version hardware. I used BDM.exe to install correct and broken NVSRAM contents on the original and patched firmware. It seems to work fine.
This needs testing on a model B version, preferably one with a corrupt NVSRAM. (Mine is still working.)
Once people report success, I'll generate installation floppy disks.
-
Checked in my TDS3034 no suffix, and it works. Impressive!
Had to only load (erase sectors, reflash) the bottom part of the hexfile. So the bit 0-0x2800000. Not just to save my calibration, but also so that it preserved all 4 channels (instead of ending up with only CH1, CH2 instead of CH1 CH2 CH3 CH4).
Some improvement suggestions:
* Also set the RTC when loading defaults. It now shows "25 BUG-2580 85:28:0k". Would be nicer maybe to set it to 1/1/2020 12:00:00 when loading default NVRAM image? And let it hide the time/date display by default (is a setting option, 'Display Date/Time On Off').
* The message "NVSRAM corrupt, using default values" does not disappear after it gets a good battery again. Would be nicer if it would not keep saying that after DS1742W battery repair.
* Would be nice if it tests the battery flag (see datasheet DS1742) and uses that (also?) to decide that the NVRAM data is bad. I think you now only do a checksum check?
* Not sure if this new code already does it, but if not then DS1742 /OSC bit clearing/setting may need attention. As in special sequency with R and W bits, just as with setting the time/date. There's more to that than simply treating the RTC registers as RAM bytes. See DS1742 datasheet for details.
* No longer let it say "To download latest firmware, visit www.tektronix.com" - because this now is the latest and greatest!
* If it sees the empty battery flag in DS1742W, let it prompt "check out eevblog.com forum for hints on how to fix my dead DS1742W battery!"
PS this version did not have the new option from your opening post: the dev team picture, the model BW options etc...
-
Had to only loadw (erase sectors, reflash) the bottom part of the hexfile. So the bit 0-0x2800000. Not just to save my calibration, but also so that it preserved all 4 channels (instead of ending up with only CH1, CH2 instead of CH1 CH2 CH3 CH4).
Thanks for testing!
I’m using BDM v4.3. How can I erase and flash a smaller region? Just provide it a smaller file? Can I start flashing at an address other than 0? That would allow me to reflash even faster.
At some point, I'll create a BDM controller software with an API so that I can use it as an MCP. I also want to be able to add breakpoints etc for better on-hardware debugging.Quote* Also set the RTC when loading defaults. It now shows "25 BUG-2580 85:28:0k". Would be nicer maybe to set it to 1/1/2020 12:00:00 when loading default NVRAM image? And let it hide the time/date display by default (is a setting option, 'Display Date/Time On Off').
Will do!Quote* The message "NVSRAM corrupt, using default values" does not disappear after it gets a good battery again. Would be nicer if it would not keep saying that after DS1742W battery repair.
It doesn't disappear because the code currently does write the default values back to the NVSRAM. I'm doing that because I wanted to preserve as much data as possible, even if there is a disruption. In reality, this is probably pointless: if there's NVSRAM corruption, chances are high that all is lost anyway. So I'll fix that.Quote* Would be nice if it tests the battery flag (see datasheet DS1742) and uses that (also?) to decide that the NVRAM data is bad.
I have a developers mode that checks this, but it's not super useful: the battery on mine gets flagged as depleted, but it still holds data.QuoteI think you now only do a checksum check?
It does quite a bit more, such as the buffer overflow check. There are some buffers that don't have a checksum. I'll have to write this down soon. I'll also put this stuff in a GitHub repo. A forum is a terrible way to distribute software...Quote* Not sure if this new code already does it, but if not then DS1742 /OSC bit clearing/setting may need attention. As in special sequency with R and W bits, just as with setting the time/date. There's more to that than simply treating the RTC registers as RAM bytes. See DS1742 datasheet for details.
The code typically reuses functions that already exist in the original firmware so that shouldn't be an issue.Quote* No longer let it say "To download latest firmware, visit www.tektronix.com" - because this now is the latest and greatest!
Makes sense!
* If it sees the empty battery flag in DS1742W, let it prompt "check out eevblog.com forum for hints on how to fix my dead DS1742W battery!"QuotePS this version did not have the new option from your opening post: the dev team picture, the model BW options etc...
For now I didn’t include the other goodies to make testing manageable.
-
Quote
I’m using BDM v4.3. How can I erase and flash a smaller region? Just provide it a smaller file? Can I start flashing at an address other than 0? That would allow me to reflash even faster.
Simply reduce the .bin file size so that it only has bytes 0-0x27fffff.
Then don’t erase flash before programming. It will then prompt many times for an ok to erase sectors as and when needed. Answer y to each prompt. 30-50 ish tines or so. -
Answer y to each prompt. 30-50 ish times or so.
Ok, I definitely see a new BDM software in my future!
-
Some improvement suggestions:
Attached is a new version. (note: firmware was broken, attachment removed)
It has these features:
The usual caveats apply: don't test this if you don't know what you're doing.
Check out this WIP GitHub repo for details: https://github.com/tomverbeure/tds3kplus
NVSRAM guard is a development/test version that has a secret Test mode to induce NVSRAM corruption. More about that here: https://github.com/tomverbeure/tds3kplus#development-mode.
I've been playing Tetris too much...
This is a release candidate. Let me know how it goes!
-
That version worked well on my TDS3034. Impressive!
I made a new BDM.exe that lets you do a partial flash erase & reprogram. Press 'Q' instead of 'p' for that. It will then only program 0-0x27fffff, and leave 0x2800000-0x3ffffff untouched so that calibration, SPC data, and model, channel numbers stays untouched. And it will not ask for confirmation each time it needs to erase just one flash sector. Attached.
-
Tried on a TDS3014B, here it does not work. Stuck in flash screen when booting.
I think the issue is with the RAM chips being different in -b models. So something in the bootloader where the XPC860 is configured for how to read/write from DRAM.
This is what it says on the diagnostic serial:QuoteUUUUUUUUUUUUUUUUUUUU
Loading Image
Boot flash checksum OK
Code flash checksum OK
0x00800000 bytes of RAM found
*** Address/Data line FAILED at 0x00000000 expected 0x55555555 actual 0xaaaaaaaa ***
*** Address/Data line FAILED at 0x00000000 expected 0xffffffff actual 0x00000000 ***
NVRAM address line check OK
NVRAM data line check OK
TBC ACQ SRAM address line check OK
TBC ACQ SRAM data line check OK
TBC Display SRAM address line check OK
TBC Display SRAM data line check OK
SuperI/O ID 0x000000b2
Uncompressing code from 0xffc40010 size 0x00000370
With the original firmware, it would not sayQuote*** Address/Data line FAILED at 0x00000000 expected 0x55555555 actual 0xaaaaaaaa ***
*** Address/Data line FAILED at 0x00000000 expected 0xffffffff actual 0x00000000 *** -
With the original firmware, it would not say
I did not expect that: this error happens in the first bootloader, before any of the changes that I made!Quote*** Address/Data line FAILED at 0x00000000 expected 0x55555555 actual 0xaaaaaaaa ***
*** Address/Data line FAILED at 0x00000000 expected 0xffffffff actual 0x00000000 ***
Here is the address map of the flash:Code: [Select]Section Start End
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━ ━━━━━━━━━━━━━━━━━
Boot/recovery 0x000000 0x03FFFF
Application, languages, padding and team photo 0x040000 0x27FFFF
Persistent journal and boot graphics/tail 0x280000 0x3FFFFF
I think that I know what's happening: I only made changes to the second section, but my firmware image contains the boot/recovery of a TDS3000. If the DRAM of a TDS3000B is different, then the boot loader of the B must be different too.
Can you send me a full flash dump of your B so that I can confirm and check how it configures the DRAM controller differently?
This would not have been a problem if you had updated the firmware the official way, with (not yet generated) floppy disks, because that only touches the second section. This is really good feedback though: it means that I should never create a new firmware image that touches the boot/recovery code, because there are different versions out there.
This also means that your BDM.exe feature that swizzles the chip selects of the NVSRAM (CS2 <-> CS6) might be risky: there's a chance that different bootloaders have that code at different locations. You might want to add a CRC check to make sure.
You can still use the guard_play image on the B, but you'll need to adapt BDM.exe so that it only reflashes the application section between 0x040000-0x27FFFF. That will always be the safest way to use BDM.exe and mimic the floppy based updater.I made a new BDM.exe that lets you do a partial flash erase & reprogram. Press 'Q' instead of 'p' for that.
Can you also make it work then it sees a "Dual" instead of "Quad" channel FT2232HL?
BTW, here is an interesting detail:QuoteNVRAM address line check OK
NVRAM data line check OK
You'd think that this does some kind of memory read/write check, but all it does is calculate the address of the NVSRAM and then... nothing. There is some evidence that there used to be code that does a check, but nobody uses it. (At least on my scope! Maybe it's different on a 3000B...) -
A good tds3000b rom image is here i think:
https://www.eevblog.com/forum/repair/tds3014-adventures-(seeking-75-75mhz-oscillator)/msg6176601/#msg6176601
May well be the case that -b boot code works for both non suffix and -b. I vaguely remember there’s an i/o pin to the xpc860 that tells ifi it is -b or -c or no-suffix, and also how many channels. The -b boot firmware reads that and then populates tables inside the xpc860 differently. Not sure - it was 5 years ago when i tried single stepping with a bdi2000 BDM debugger… -
A good tds3000b rom image is here i think:
The flash dump is corrupt: both the recovery image and the application image checksum is incorrect and doesn't match the checksum calculation of the bootloader. However, the bootloader of the flash dump is good enough. It loads different values for the DRAM controller which impacts timing and address mapping. It indeed reads the value of 3 strap pins and programs different values based on that.
https://www.eevblog.com/forum/repair/tds3014-adventures-(seeking-75-75mhz-oscillator)/msg6176601/#msg6176601
I also checked the timings for the other chip selects: the B version adds extra wait cycles pretty much everywhere. For flash, read and write transactions go from 4 to 8 clock cycles. Floppy drive controller write accesses even go from 3 to 10. -
Another tds3000b binary flash dump attached. This one works ok in my TDS3014B.
I tried to blend in with your new firmware image, but it still does not work.
Attempt #1 was to preserve boot code from 0-0x4000. This was very difficult because the flash chips have sector size of 0x8000 in their bottom boot sector. No luck in the end.
Attempt #2 was to preserve boot code from 0-0x40000. Scope boots but then stumbles into reboots. With this on the diagnostics port:QuoteUUUUUUUUUUUUUUUUUUUU
Boot flash checksum OK
Code flash checksum OK
0x00800000 bytes of RAM found
DRAM address line check OK
DRAM data line check OK
NVRAM address line check OK
NVRAM data line check OK
TBC ACQ SRAM address line check OK
TBC ACQ SRAM data line check OK
TBC Display SRAM address line check OK
TBC Display SRAM data line check OK
SuperI/O ID 0x000000b2
Loading Image
Uncompressing code from 0xffc40010 size 0x00000370
Enabling cache
Entering usrRoot
Enabling the MMU
sysClkRateSet using 50 MHz
Enabling I/O system
excInit called
Class 17 Level 3 hwResetTBC(): Installing Machine Check Exception handler. 13:58:00 10/23/2026 (thread: StartUp)
Class 7 Level 3 hwI2CAppKeySearch: new device I2C/APPKEY2 slot 2 addr 0xa2
13:58:01 10/23/2026 (thread: StartUp)
TBC reset count = 0
Doubling core clock ... complete
software emulation
Exception current instruction address: 0x00349ba8
Machine Status Register: 0x0000lass 17 Level 3 hwOnBusErr(): Machine Check Exception - Rebooting... vecNum 4096 13:58:09 10/23/2026 (thread: exec)
cacheDisable (0);
Calling romInitUUUUUUUUUUUUUUUUUUUU
Boot flash checksum OK
I think the reason for different RAM read/write timings is that the -b model doubles CPU clock speed at some point. Without adjusted timings it would be trying to access the chips too fast i guess.
-
Another tds3000b binary flash dump attached. This one works ok in my TDS3014B.
If you're not yet tired about running these tests: I've attached a new full-flash binary (note: firmware was broken, attachment removed) that has the same application section as the previous one, but the boot/recovery section and the calibration section are now coming straight from your new one. If that doesn't work, I'll need a TDS3000B device for further debugging... which is hopefully soon because a broken one is on its way. (Seller states that it hangs at the boot flash image, so probably just an NVSRAM issue, which is exactly what I need anyway!)
I tried to blend in with your new firmware image, but it still does not work.QuoteI think the reason for different RAM read/write timings is that the -b model doubles CPU clock speed at some point. Without adjusted timings it would be trying to access the chips too fast i guess.
I had been wondering about a few day ago but I couldn't really figure it out at the time. I've now looked at the clock doubling code and here's what I've come up with:- There's this 3-bit configuration strap, connected to the Port D data register of the MPC860, that was already used to determine how to program different bus speeds
- The same strap is used to determine whether or not reprogram the PLL with a x2 divider. This doubles the CPU clock speed from 50 MHz to 100 Mhz.
- For the bus speed programming, it uses a strap threshold value of 5, while the clock doubling uses a threshold value of 2. So the bus speed configuration and CPU speed selection are decoupled.
- When the x2 divider is enabled, a bus clock divider is set to 2. So your speculation that the different timings are because of the clock doubling is not correct: even when the CPU is running at 50 MHz, it still the runs at those new timings. The x2 PLL and /2 bus divider cancel each other out.
- I initially assumed that model used an MPC866 because those official support 100 and 133 MHz, but that's not the case. There is no official MPC860 that supports 100 MHz for the CPU, so Tektronix must have getting binned parts.
- The MPC860 in my scope is a XPC860DCZP33C1. It runs at 50MHz, but Freescale documents only list a maximum clock speed of 33MHz. So this one is overclocked beyond its spec as well.
-
This flash_rom_4mb_guard_play_u_tds3054b.bin in the TDS3014B gave the same as what i had yesterday: booting, but then crashing. Diagnostics says this:Quote
UUUUUUUUUUUUUUUUUUUU
Boot flash checksum OK
Code flash checksum OK
0x00800000 bytes of RAM found
DRAM address line check OK
DRAM data line check OK
NVRAM address line check OK
NVRAM data line check OK
TBC ACQ SRAM address line check OK
TBC ACQ SRAM data line check OK
TBC Display SRAM address line check OK
TBC Display SRAM data line check OK
SuperI/O ID 0x000000b2
Loading Image
Uncompressing code from 0xffc40010 size 0x00000576
Enabling cache
Entering usrRoot
Enabling the MMU
sysClkRateSet using 50 MHz
Enabling I/O system
excInit called
Class 17 Level 3 hwResetTBC(): Installing Machine Check Exception handler. 09:55:32 10/24/2026 (thread: StartUp)
Class 7 Level 3 hwI2CAppKeySearch: new device I2C/APPKEY2 slot 2 addr 0xa2
09:55:32 10/24/2026 (thread: StartUp)
TBC reset count = 0
Doubling core clock ... complete
software emulation
Exception current instruction address: 0x00349ba8
Machine Status Register: 0xlass 17 Level 3 hwOnBusErr(): Machine Check Exception - Rebooting... vecNum 4096 09:55:41 10/24/2026 (thread: exec)
cacheDisable (0);
Calling romInitUUUUUUUUUUUUUUUUUUUU
Boot flash checksum OK
Code flash checksum OK
0x00800000 bytes of RAM found
DRAM address line check OK
DRAM data line check OK
NVRAM address line check OK
NVRAM data line check OK
TBC ACQ SRAM address line check OK
TBC ACQ SRAM data line check OK
TBC Display SRAM address line check OK
TBC Display SRAM data line check OK
SuperI/O ID 0x000000b2
Loading Image
Uncompressing code from 0xffc40010 size 0x00000576
Enabling cache
Entering usrRoot
Enabling the MMU
sysClkRateSet using 50 MHz
Enabling I/O system
excInit called
Class 17 Level 3 hwResetTBC(): Installing Machine Check Exception handler. 09:55:47 10/24/2026 (thread: StartUp)
Class 7 Level 3 hwI2CAppKeySearch: new device I2C/APPKEY2 slot 2 addr 0xa2
09:55:47 10/24/2026 (thread: StartUp)
Class 2 Level 3 acqWaitForAcqDone: timed out, sysjmp = 0x25
09:55:48 10/24/2026 (thread: StartUp)
Class 2 Level 3 acqAcquireScalarStats: acqWaitForAcqDone failed.
09:55:48 10/24/2026 (thread: StartUp)
Class 3 Level 3 calVertSetupForInternalSineWave failed. 09:55:49 10/24/2026 (thread: StartUp)
TBC reset count = 5
Doubling core clock ... complete
software emulation
Exception current instruction address: 0x00349ba8
Machine Status Register: 0x0000b032
Condition Register: lass 17 Level 3 hwOnBusErr(): Machine Check Exception - Rebooting... vecNum 4096 09:55:56 10/24/2026 (thread: exec)
cacheDisable (0);
Calling romInitUUUUUUUUUUUUUUUUUUUU
Boot flash checksum OK
Code flash checksum OK
0x00800000 bytes of RAM found
DRAM address line check OK
DRAM data line check OK
NVRAM address line check OK
NVRAM data line check OK
TBC ACQ SRAM address line check OK
TBC ACQ SRAM data line check OK
TBC Display SRAM address line check OK
TBC Display SRAM data line check OK
SuperI/O ID 0x000000b2
Loading Image
Uncompressing code from 0xffc40010 size 0x00000576
UUUUUUUUUUUUUUUUUUUU
Boot flash checksum OK -
This flash_rom_4mb_guard_play_u_tds3054b.bin in the TDS3014B gave the same as what i had yesterday: booting, but then crashing. Diagnostics says this:
Found the problem! I'm using a hardware clock counter to generate entropy for the random MAC address generator. I don't know why this fails, I'd need the hardware to figure that out... This doesn't trigger on my TDS3052 because it doesn't have Ethernet, but it triggers on yours.
...
I've replaced the reading of that counter and now use the tickGet() VxWork function instead. This should solve the issue.
Update flash image (based on your tds3054b golden image) in attachment.
-
That worked better. All looks good at first sight. Except for the dev team picture. Scope freezes if i try to get that. Maybe that dev team is angry with us now and no longer wants to show up in this theatre?
-
That worked better. All looks good at first sight. Except for the dev team picture. Scope freezes if i try to get that. Maybe that dev team is angry with us now and no longer wants to show up in this theatre?
Something like that: your flash image doesn't contain the dev team photo. Chances are that it was only a non-B version thing that was removed later on because it wasn't used anyway.
It's too risky to package the dev photo and install it if it's not there because that would introduce corner cases for the floppy disk updater. Instead, the firmware now checks for the presence of a PNG file at the expected location. If it's not there, a Dev Team Photo menu is not added.
New firmware in attachment.