Tektronix TDS500/600/700 NVRAM floppy backup and restore tool

[dxl]

Definitely a great tool. And *much* easier to use than my tekfwtool i wrote long time ago! :-)

[fisafisa]

Hi.
Why writing random data?
Can´t you simply write the correct data to the NVRAMs?
I am in the middle of fixing a NVRAM problem myself. (the DS1486 losing data)

In any case note that the DS1250 NVRAM is mapped in memory with the first quarter of its memory mapped at the end.
So no simple read from floppy and write to chip using a programmer.

[flyte]

Definitely a great tool. And *much* easier to use than my tekfwtool i wrote long time ago! :-)

I think you deserve a ton of credit for that tekfwtool ! Not in the least for the approach of
dropping flash target code into the device. Certain spy agencies would appreciate your
craft ... 

Mine is basically a script using a couple of VxWorks functions. And it can't flash.

[flyte]

Hi.
Why writing random data?
Can´t you simply write the correct data to the NVRAMs?
I am in the middle of fixing a NVRAM problem myself. (the DS1486 losing data)

In any case note that the DS1250 NVRAM is mapped in memory with the first quarter of its memory mapped at the end.
So no simple read from floppy and write to chip using a programmer.

Because some parts of the NVRAM never change, and those are the most important ones. So if you write a dump, which you took, into an NVRAM which already contains the same data, you won't actually know whether the write operation succeeded or it did nothing (due to some write protection, etc.) and it may just seem to work because the correct data was already there to start with. Like I said, I do not recommend loading random data unless you know what you are doing and have ways to recover.

I will see if it's possible to write a small tool which verifies checksums, so everyone can be sure they took a correct dump of the cal values.

It's indeed possible Tektronix "messed" around with mapping memory space onto the NVRAM, which would prevent unaltered external writing in a linear fashion. But how sure are you about this? It seems kind of weird. Could be it's your programmer swapping mappings?

In any case, it's the DS1486 which contains all important calibration data. The DS1250 is just there to remember settings, waveforms and error logs.

Btw, what leads you to believe the DS1486 is "losing data"? It's different with every dump, that's perfectly normal.

[flyte]

FYI: just finished the checksum tool, see update in first post

[bsdphk]

The firmware in these scopes is quite fascinating, not only do they run a VXWorks kernel, they run the entire interactive plan of the GUI in SmallTalk :-)

I have not studied the code which controls the CALRAM access in detail, but it looks like a pretty trivial software/hardware handshake mekanism, involving crucially, the switch you poke via the ventilation hole.

Btw, it looks like all the firmware is there for ethernet support, I wonder how hard it would be to add the necessary hardware?

[flyte]

The firmware in these scopes is quite fascinating, not only do they run a VXWorks kernel, they run the entire interactive plan of the GUI in SmallTalk :-)

I have not studied the code which controls the CALRAM access in detail, but it looks like a pretty trivial software/hardware handshake mekanism, involving crucially, the switch you poke via the ventilation hole.

Btw, it looks like all the firmware is there for ethernet support, I wonder how hard it would be to add the necessary hardware?

Correct, these TDSes are SmallTalk scopes    I agree, it was pretty advanced for their era. But it looks like Tektronix shoot themselves in the foot eventually, because later TDS scopes then all came with a Windows OS, probably due to demand, competitors and marketing. So then they seemed forced to keep their 68K/PowerPC/SmallTalk scope-marvell as a 2nd computer inside another Windows/Intel computer. The Windows OS was basically there to display a remote console into the VxWorks system    They even made cumbersome BIOS/hardware on the TDS6000/7000 series which allowed shared access by the 68K/PowerPC board to the disk and resources of the Wintel platform 

Adding Ethernet might be possible. There seems to be evidence of the PCMCIA option checking for a LAN card in it. If the hardcoded driver is indeed in there somewhere, it's still not clear which card model or make it is expecting. Knowing Tektronix' choices of that era, my bet would be on a 3Com LAN card. If it all works, the question would be whether it'll do anything useful at all. But I'll leave that challenge to others 

[flyte]

Again a new update of the tools! See original post.

While I was at it, I figured I could also implement a backup script for the calibration EEPROMs located on the acquisition board. Starting with firmware revision 4.x (-B series scopes and up), Tektronix decided to store factory calibration constants in two 24C04 EEPROMs on the acquisition board, instead of in a protected NVRAM region. For the sake of clarity: calibration constants are present both in NVRAM and in the acquisition board EEPROMs, it's not that the EEPROMs replaced the NVRAM and you no longer need it! My understanding is that if you mess up the NVRAM, your scope may be recalibrated by a service center, whereas if something happens to the acquisition EEPROM constants ...  Please note the script only reads one EEPROM or 0x200 bytes. It seems the second EEPROM was never used by any firmware, and that has been confirmed by others reading out the chips directly, i.e. the second chip is always empty.

The checksum verifier tool has now been updated to handle verification of the acquisition EEPROM dumps as well. The tool will automatically attempt to determine the dump type by looking at the file size.

This set of tools should now allow to safeguard and check all device-specific data on all TDS5/6/7xx series. In case you find any bugs or unsupported interpretation of your NVRAM/EEPROM, please let me know and I'll correct it.

[Tardz]

Thanks for these tools.
I've done today a backup of NVRAM and EEPROM with your tools without any problem.
Date code of my DS1250Y is 9750U an for DS1486, 9731E.
My scope is a TDS784C firmware V5.3e option 13 1F 1M 2F.
It's time to change the NVRAM.

Thank you so much!
Yves

[Dogbert01]

Tried both the NVRAM floppy dumper and the minimal floppy dumper on a TDS744A scope but neither would dump the NVRAM. When I examined the floppy I find that the startup.bat files have been changed and are unreadable. Firmware version is 1.1e.

Does anyone know if the TDS744A's use a different memory space for the NVRAM?

Thanks.

[HardyG]

I've also found that issue but only if I do use a floppy (FAT) formatted by e.g. Windows. At least in my case this does not happen using a floppy formatted by the scope itself.

[HardyG]

Hi and thanks a lot for providing this tool.

I just wanted to report that I've found that the dumps done by the tdsNvramFloppyDumper seems to differ from the ones I've done using the tektool.
I know that there are areas which will always change (like the RTC area and also the GUI area) but I've found several big areas where the dump shows 0x00 using the tektool but showing 0xF6 using the floppy tool and I'm not sure if the floppy tool gives reliable results...

Please find two dumps attached taken shortly one after another - one done by using the tdsNvramFloppyDumper and the other one using the tektool (and for convenience just appended the TIMEKEEPER and the SRAM). I've attached two files, DUMP.bin (done using tdsNvramFloppyDumper v4) and nvram_COMBINED.bin (done using the tektool comibing the resulted separate dumps afterwards). I'm just not sure which one of the dumps will be correct and which are not. For now I think the dumps done using the tektool are more "reliable"...

I've also tried using the tdsNvramFloppyDumper having the NVRAM protection ON as well as switching it OFF with different timing after the scopes boot started (after the first flashing of the floppy drives LED, after the splash screen appeared, after the scopes info screen appeared). I'm aware that just reading the NVRAMs should not be influenced by this switch but as far as I can see it may do so anyway. I did not dig too deep into that issue because I'm not sure (as mentioned above) if the dumps done by tdsNvramFloppyDumper are reliable anyway.

(BTW: I'm using a TDS754D FV v6.6e having a serial # B02xxxx which I've upgraded to TDS784D (configuration resistors as well as BW limiting caps) as well as adding some SW options (like 1M - 2M is not possible with my model because it's only equipped with the 32k x 8 RAMs), I do have two PC setups, one Windows 10 using NI488 PCII as PCI card and one Windows 98 using PCII as ISA card. I do also use an option 13 to console adapter cable)

[Dogbert01]

HardyG,

Thank you for the reply. I did format the floppy on the scope but I still am not able to dump the NVRAM.

If I use the tdsNvramFloppyDumper the startup.bat file gets changed to this 愀歳灓睡∨癮慲摭浵数≲ㄬ〬へ㐬〰〰猬獹硅捥捓楲瑰∬摦㨰港摶浵⹰灡≰਩.

If I use the tdsNvramMinimalFloppyDumper the startup.bat file does not change but there is no NVRAM dump.

I have ordered parts to build the console connector to see if I can use that to dump the NVRAM.

[HardyG]

Dagobert01,

did you check if the floppy drive cable is correctly connected to your processor board? maybe it‘s worth to check or just release and re-insert it again...

[HardyG]

NVRAM dump by tektool vs. tdsNvramFloppyTools_v4
================================================
1. Environment preparation
    TDS754D (resistors / caps upgraded to TDS784D, some SW options upgraded)
    Setup the scopes GPIB address to "1"
    PC (Windows 98) equipped with NI488 PCII ISA GPIB card and connect the scope (by GPIB) with the PC
    (The GPIB tools/environment needs to be set up correctly on that PC)
    You do need the "tektool" on that PC
    Prepare a floppy (formated by the scope itself and copy the respective two files from tdsNvramFloppyTools_v4 onto that floppy
    You may or may not attach a console adapter to see any possible erasing message
   
2. TDS preparation (optional - may ease the compare later on)
    You need the tool "TDSError Log Viewer" to erase the error logs on
    Switch the scope on (in normal mode)
    Use the "TDSError Log Viewer" to clear the error logs
    Delete all "secure" files on the scope - so waveforms stored etc.
       (TDS: "Utility" --> "Config" --> "Tek Secure Erase Memory" --> "OK Erase Setup & Ref Memory")
    Perform a factory reset (TDS: "Setup" --> "RECALL Factory Setup" --> "OK Confirm Factory init")
      
3. Execution (in a row)
   a) Scope is OFF
       Put NVRAM write protection SW in position "protection OFF / Monitor mode"
       Switch the scope ON and wait shortly (it's taking only seconds until it's booted to the "monitor" SW.
       (Remember: The scope seems to "hang" and has nothing on the screen what's absolutely correct)
       dump NVRAM by tektool
       Switch the scope OFF again
       Put NVRAM write protection back into "protection ON"
   b) Place the floppy prepared with the tdsNvramFloppyTools_v4 into the scopes drive
       Switch the scope ON and wait until the tool completed the dump...
       dump NVRAM by tdsNvramFloppyTools_v4
       Drop the floppy out of the scope
       Switch the scope OFF
   c) Put NVRAM write protection SW in position "protection OFF / Monitor mode"
       Switch the scope ON and wait shortly (it's taking only seconds until it's booted to the "monitor" SW.
       (Remember: The scope seems to "hang" and has nothing on the screen what's absolutely correct)
       dump NVRAM by tektool
       Switch the scope OFF again
       Put NVRAM write protection back into "protection ON"
      
4. Compare
Now having the 3 results let us prepare the compare.
The tektool usually giving you separate files for TIMEKEEPER and SRAM.
For an easy compare we should link the two files after each other (first TIMEKEEPER than append SRAM).
This can performed by many tool - e.g. just binary copy /b file1.bin + file2.bin resulting_file.bin
Now we do have 3 equally sized files which we are able to compare easily.

If we do compare the first and the last one (both done using tektool) you can see that there are only small differences.
There are always small changes, e.g. the real time clock at the start of the files but also some GUI settings which are stored.
Also if there are any errors the scope will log these during startup.

Back to the comparison having a look on the first and the last dump we do see some slight changes (normal as described above).
If we do compare one of the tektool dumps against the dump performed by the tdsNvramFloppyTools_v4 (taken as second dump so between the
two above in a timely manner) we do see a lot more differences - some seem to have "more" content in the dump done by the tektool, some
in the dump done by the tdsNvramFloppyTools_v4. Because lot of the changes between the first (tektool) dump and the second (tdsNvramFloppyTools_v4)
dump seem to be gone in the thired (second tektool) dump this seems not to be content just created / changed during the startups
there seems to be an inconsistence between the dumps taken by the tektool vs. taken by the tdsNvramFloppyTools_v4.

Does maybe the "NVRAM protection switch" does have any influence on the NVRAM content also if it's only read???
Lets try a fourth dump using the tdsNvramFloppyTools_v4. This time we'll have the tdsNvramFloppyTools_v4 floppy in the scopes drive and
the NVRAM protection switch still "ON" when switching on the scope but as soon as we see the floppy LED flash for the first time
we do change the NVRAM protection switch to "OFF" so the dump taken using the tdsNvramFloppyTools_v4 is done while having the
NVRAM protection switch OFF.
After the dump is done (you'll recognize when the floppy is finished to write data - it seems sometimes the "finished" dialog
of the tdsNvramFloppyTools_v4 is not in that configuration) we drop of the floppy and switch of the scope. Do not forget to switch the
NVRAM protection switch to ON again. If that switch does not make any difference in reading the NVRAM than the fourth dump should only
have slight differences to the second one (also made using the tdsNvramFloppyTools_v4) which will mean that the dumps made using
the tdsNvramFloppyTools_v4 are inconsistent with the ones made using the tektool and therefor maybe faulty. If that fourth dump has
the same bigger differences like the tektool ones compared with the tdsNvramFloppyTools_v4 ones this shows that having the
MVRAM protection switch in one or the other position DOES IN FACT make a big difference in the memory read.

I did so and found the fourth dump does also have bigger differences to the second dump (both made using the tdsNvramFloppyTools_v4)
but the fourth dump has also bigger differences compared with the tektool ones. What does that mean???

Ones for sure: Dumps differ very much between having the NVRAM protection switch in ON or OFF position!
But where do that big differences come from between having the NVRAM protection OFF doing a dump using tdsNvramFloppyTools_v4 and a dump
done using the tektool?

[flyte]

Tried both the NVRAM floppy dumper and the minimal floppy dumper on a TDS744A scope but neither would dump the NVRAM. When I examined the floppy I find that the startup.bat files have been changed and are unreadable. Firmware version is 1.1e.

Does anyone know if the TDS744A's use a different memory space for the NVRAM?

Thanks.

This seems like a very old firmware. I did not have the possibility to test it on firmware that old, and it may indeed not work.

[flyte]

HardyG,

Thank you for the reply. I did format the floppy on the scope but I still am not able to dump the NVRAM.

If I use the tdsNvramFloppyDumper the startup.bat file gets changed to this 愀歳灓睡∨癮慲摭浵数≲ㄬ〬へ㐬〰〰猬獹硅捥捓楲瑰∬摦㨰港摶浵⹰灡≰਩.

If I use the tdsNvramMinimalFloppyDumper the startup.bat file does not change but there is no NVRAM dump.

I have ordered parts to build the console connector to see if I can use that to dump the NVRAM.

As pointed out earlier, make sure you format the floppy using the scope itself or some old PC. A disk formatted on a recent OS is unlikely to work, especially with the older firmware versions.

[flyte]

HardyG,

Thanks a lot for such an extensive report.

You are correct, your dumps taken by the tekfwtool have valid checksums whereas those taken by the script tools of the post are mostly invalid.

However, scrolling through your dumps, it looks like the problem could be simple. There are numerous READ FAIL log entries in the last dump, which could mean that either you are using a floppy disk with errors, either your TDS floppy drive is dirty or not working. Unless that would be from a past episode.

It is of crucial importance you use an error-free floppy disk. I've found out that even if sectors are properly marked as bad, the TDS doesn't handle things very well.

When running the scripts, also make sure the scope is as idle as possible and the GPIB is disconnected, as it may generate high-priority interrupts.

Please note you should not totally rely on the observed binary contents of the dump. I've included a Java based tool in the post which can verify the checksums of the crucial parts of NVRAM and acquisition EEPROM dumps. There are large parts of the NVRAM which contain garbage from some startup or debugging tests, and they may change frequently for no good reason.

Checking your dumps with the Java-based verifier tool does reveal a small bug in it: on one occasion it says all checksums are valid even with bad dumps. By looking at it closely, it does show all checksums are zero (both computed and as-found in the dump, by accident). I can't fix this as in theory a checksum with value 0x0 could actually exist.

One more thing to try would be too see if you get different results with the "minimal" dumper script vs. the normal GUI-based script (check the readme with the scripts for further info).

Please do post your further findings.

[flyte]

And there is a second thing if I recall well from my testing: you must remove any console adapter when using the dump scripts. It seems this extra high priority VxWorks shell task interferes with the dumping task.

[Dogbert01]

flyte,

I formatted the floppy using the scope utility.

I think that it is great that you created this tool.

I would attempt to update the firmware, but then I would need to calibrate the scope.

I have a GPIB PCI card and am now waiting for a GPIB cable to arrive so that I can dump the NVRAM data.

[flyte]

flyte,

I formatted the floppy using the scope utility.

I think that it is great that you created this tool.

I would attempt to update the firmware, but then I would need to calibrate the scope.

I have a GPIB PCI card and am now waiting for a GPIB cable to arrive so that I can dump the NVRAM data.

You're only way out with such an old firmware is likely to be the GPIB tekfwtool, if it works with it at all.

Upgrading firmware does not necessarily mean you need to recalibrate. Tektronix held calibration format stable across several releases of scopes and firmwares.

The checksum tool I've posted detects nearly all variants, I've identified 5 core variants so far for all firmwares of all TDS5/6/7ABCD scopes. You can run it on your NVRAM dump and check if it finds a full match (with non-zero checksums). If it does, you should be able to upgrade firmware to the detected firmware format without calibration data problems.

But under any circumstance, backup the NVRAM first. Flashing a new firmware with incompatible calibration format will reset all NVRAM calibration to firmware default values! These seem to be firmware default values and not default values for a scope to work. E.g. if a calibration constant would need to be 1.25 as a default for the average scope to work, the firmware default values may be set to 0.0, effectively rendering the scope non-operational.

[flyte]

The checksum tool I've posted detects nearly all variants, I've identified 5 core variants so far for all firmwares of all TDS5/6/7ABCD scopes. You can run it on your NVRAM dump and check if it finds a full match (with non-zero checksums). If it does, you should be able to upgrade firmware to the detected firmware format without calibration data problems.

And I need to add to that this only applies to the calibration data format. For example, the TDS754/84D have different acquisition hardware starting with serial number B040000, and the respective firmware 7.4e will only run on that type of hardware, even if the calibration data base structure is the same. For that particular type of scope with serials below B040000, highest compatible firmware seems to be 6.6e.

[HardyG]

Ahhh - thanks a lot, flyte.
At least for the TIMEKEEPER that did the job.
All checksums are reported to be VALID but the SRAM ones are 0x00 - so maybe unchecked / invalid.
The SRAM content also still differs significantly between floppy tool and tektool_0 - but maybe that doesn‘t matter...

Where does the checksum tool derive the firmware versions from?
My scope is an early TDS754D (B02xxxx) (upgraded to TDS784D) having firmware 6.6e (which I also dumped and checked against an original firmware 6.6e image found it‘s matching) but the checksum tool reports something like

checking the calibration eeprom: firmware prototype acqEEPROM-TDS784D-v7.4e_TDS784C-v5.2e
checking the TIMEKEEPER: firmware prototype NVRAM-TDS784D-v7.4e
checking the SRAM: firmware prototype TDS524A-v3.8.7e - but all checksums are 0x00

Are you able to explain this, please?

I‘m also not sure how writing new NVRAMs may work using the floppy tool because if your NVRAMs are dead and you had the need to replace them with new ones the scope does not boot to the point where the floppy tool gets started. Am I wrong?

[flyte]

Ahhh - thanks a lot, flyte.
At least for the TIMEKEEPER that did the job.
All checksums are reported to be VALID but the SRAM ones are 0x00 - so maybe unchecked / invalid.
The SRAM content also still differs significantly between floppy tool and tektool_0 - but maybe that doesn‘t matter...

Where does the checksum tool derive the firmware versions from?
My scope is an early TDS754D (B02xxxx) (upgraded to TDS784D) having firmware 6.6e (which I also dumped and checked against an original firmware 6.6e image found it‘s matching) but the checksum tool reports something like

checking the calibration eeprom: firmware prototype acqEEPROM-TDS784D-v7.4e_TDS784C-v5.2e
checking the TIMEKEEPER: firmware prototype NVRAM-TDS784D-v7.4e
checking the SRAM: firmware prototype TDS524A-v3.8.7e - but all checksums are 0x00

Are you able to explain this, please?

I‘m also not sure how writing new NVRAMs may work using the floppy tool because if your NVRAMs are dead and you had the need to replace them with new ones the scope does not boot to the point where the floppy tool gets started. Am I wrong?

You shouldn't split the NVRAM dumps. The checksum verifier expects the RTC NVRAM (first) and main NVRAM (2nd) to be in one dump as they appear in memory. Not that it really matters much, as all important cal data is stored in RTC, the other NVRAM is just there for waveform and settings storage. But it never hurts to back it up.

The checksum verifier tool derives the firmware versions based on a guess. It verifies all known checksummed sections (listed), and if it finds one particular set where all checksums match, it considers the NVRAM must be valid and originating from that particular FW version. As I said, over all scopes I've identified 5 different key firmware versions based on the structure of the NVRAM. The tool will only report one of those prototypes if valid, which is not necessarily the actual firmware on the scope, albeit one close to it. As mentioned, the tool may output a valid match/checksum if it accidentally matches the garbage data, usually when 0x00. This can't be fixed, as it may actually be a valid checksum value in some cases. It's mainly because Tektronix chose a very weak checksum, a simple addition, if one can call this a checksum at all.

If the NVRAMs are empty, the scope will initialize them with firmware default values (it's not calibration defaults for the average scope, see previous message!). After 1-2 restarts, it will boot with these default values, but measurement will be completely off or even impossible. But it will boot and that's enough for the script to run!

So, in the end, which was the problem with the bad dump? Bad floppy? GPIB/console port attached?

[HardyG]

Thanks a lot for the explanations, flyte.
The problem was that I had console as well as GPIB attached.
Does disconnecting them just lower the chances to get faulty dumps or does it completely eliminate it giving reliable dumps every time? Does it make sense to do a „2 out of 3“ dumps or something to be sure?