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

[flyte]

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?

It never hurts to do multiple dumps. Yes, I think it's a question of lowering chance of a corrupt dump, but I'm no VxWorks expert and even less so when it comes to the internals implemented by Tektronix. But I've noticed having all sorts of extra interrupts does no good to the dump script. Make sure it is simply idle without anything connected and not displaying/triggering on signals, and take 2-3 dumps to be on the safe side.

In any case, you should rely on the Java-based checksum verifier tool to check if cal data in the dump is valid or not. That's why I've added it. All checksums should be valid and in general non-zero (1/65536 chance it's a valid zero), a single firmware profile should have been indentified, and performing the check over multiple dumps should always yield the same checksum number, with the exception of the sections DIAG, STATE and ENVIRONMENT which can change based on the current settings of the scope. Sections PFCAL, INTCONST and HWACCOUNTANT as well as the acquisition EEPROM section ACQEEPROM (or the EXTCONST section for TDS---A series scope which have none and store everything in NVRAM) should remain invariant across any dump taken. That's where the golden data is stored.

[HardyG]

Excellent - thanks a lot, flyte 

[BrianAS]

Hi,I am new here and have just started playing with TDS scopes . I have used the NVRam minimal dump s/w on my TDS744 -- please note this is not an 'A,B,C,D' version its an original no suffix at all , it seems to have worked first time . I have searched through the .bin file using a HEX editor HxD and the error log is fairly easy to spot but the area where the options are placed seems very hard to locate visually as the locations expected dont contain just a zero or a one .
Firmware version is V1.0e , I had my doubts as everyone seems to have at least an 'A' version scope or better .
Has anyone else used this s/w on such an old scope , was it successful .
Also the little roms 27C04 , located at U1052 and U1055 are actually fitted on my scope , if not used for the later purpose of retaing a copy of CAL data , what were they used for ??

This is a great tool , thank you Flyte for your effort .

[.ctro]

Hi all! Can anybody send dump for TDS520b? I've bricked mine 

[sorenkir]

Hi all! Can anybody send dump for TDS520b? I've bricked mine 

Hi,
Dump for 520b is in my post.
Michel.

[Alfons]

Just wanted to report that Nvdump has worked with NvramMininmalFloppyDump with my TDS744A FW1.1e (upgrade to TDS784A). NvramFloppyDump was not recognized by the device. Anyway, the dump file was written. I first had to format the disk under Windows (fast formatting turned off!), Then it worked.

[ragge]

Hi all,

Just as a convenience measure, I added a version that dumps the NVRAMs and the EEPROMs in one sweep, called "tdsNvramEepromFloppyDumper".

It is available as part of a kit of Tektronix TDS tools slightly modified to work on Linux, and with ARM CPUs to be usable with e.g. a Raspberry
Pi. Feel free to use it anyway you want, including distributing it with tdsNvramFloppyTool if you like.

The kit is available here:
https://github.com/ragges/tektools

Happy measuring,

Ragnar

[flyte]

Hi all,

A new version of the scripts is available. Now it's possible to write the acquisition EEPROMs as well. Forum member @ragge had a superb and intriguing idea that maybe the core function of the EEPROM read script might also work the other way around, which turned out to be the case. It does switch read or write mode depending on the parameter order when invoked.

For the sake of testing and self-sacrifice to this forum I did go where no man has gone before and I attempted to destroy one of my own acquisition boards by loading a dump will all zeroes into the EEPROMs of the device. The scope failed badly, but I was able to recover it just fine by again loading the backup dump taken earlier into the EEPROMs. All data matched again. So it works. All with the scripts of course.

However, you have to consider that before attempting any repairs using the EEPROM write scripts, you should do everything in your power to read the contents of original EEPROMs, including desoldering them and attempting to recover information from them in case hardware no longer works as expected. The calibration values stored in these EEPROMs are unique to the device and many seem to have been set at production time in the factory. Replacing them with a dump from a different device will make the scope "work" but likely never render its former optimal performance again.

Make sure you read the info.txt in the archive first!

The checksum verifier is now part of the archive and it has also been updated to issue a warning in case of dumps with valid checksum 0. This is often the case when a dump failed with all zeroes, yet it's marked as having a valid checksum. As 0 is still a valid checksum, the tool can't exclude this case but it now issues are warning you should check by hand whether it makes sense or not.

If you like the update and use the tool, pushing the thanks button never hurt anyone!   

-- flyte

[Neomys Sapiens]

Hi all,

A new version of the scripts is available. Now it's possible to write the acquisition EEPROMs as well. Forum member @ragge had a superb and intriguing idea that maybe the core function of the EEPROM read script might also work the other way around, which turned out to be the case. It does switch read or write mode depending on the parameter order when invoked.

For the sake of testing and self-sacrifice to this forum I did go where no man has gone before and I attempted to destroy one of my own acquisition boards by loading a dump will all zeroes into the EEPROMs of the device. The scope failed badly, but I was able to recover it just fine by again loading the backup dump taken earlier into the EEPROMs. All data matched again. So it works. All with the scripts of course.


-- flyte

Kudos for this critical experiment.

[flyte]

Kudos for this critical experiment.

No problem, due to the lack of other models, it was "only" a TDS784D, not much to loose there!

Well, I figured at worst I would have to take out the EEPROMs and reprogram them externally.

Actually, the NVRAM is worse. One day I experimented that badly with it when making those floppy scripts I somehow managed to lock the scope in the boot loader. I still don't know what exactly it didn't like in there. That was definitely less fun!

[worsthorse]

@flyte and @ragge... very nice work here.    

i acquired a TDS520 yesterday and i found this thread while i was gathering tools and information to repair it.  your software is going to save me an awful lot of time   thanks!

i think i saw a post from the author of the tekfwtool... thanks to them, too.

[EngelenH]

So here is a slight sidetrack on this topic.

I have noticed that there are on Amazon and Ebay (far too expensive usually) floppy disk replacement devices. Essentially taking the floppy cable (different versions exist both with the classic flat cable and with a ribbon connector as in the TDS scopes) on one end and offering a USB port on the other.

Thus giving your scope a USB port instead of a floppy. Would this script still work on such a device? I would link which device I am referring to but not sure on forum policy in the matter. They are easy to find.

[Neomys Sapiens]

So here is a slight sidetrack on this topic.

I have noticed that there are on Amazon and Ebay (far too expensive usually) floppy disk replacement devices. Essentially taking the floppy cable (different versions exist both with the classic flat cable and with a ribbon connector as in the TDS scopes) on one end and offering a USB port on the other.

Thus giving your scope a USB port instead of a floppy. Would this script still work on such a device? I would link which device I am referring to but not sure on forum policy in the matter. They are easy to find.

I have seen them too. But there seem to be a lot of aditional conditions. I do not trust them and I will not have them distract me from the hunt for a proper USB-equipped Tek scope.

[CaptDon]

My TDS644A has the DS1286 part which is listed as having only 50 bytes of memory
and my TDS644B has the DS1486 device listed as 128k of memory. My question is this,
I have done the minimal floppy dump for both scopes. I got the 640k dump.bin file for
each scope. What data was produced for the DS1286 if it only had 50 bytes of memory?
Thanks!!

[ragge]

My TDS644A has the DS1286 part which is listed as having only 50 bytes of memory
and my TDS644B has the DS1486 device listed as 128k of memory. My question is this,
I have done the minimal floppy dump for both scopes. I got the 640k dump.bin file for
each scope. What data was produced for the DS1286 if it only had 50 bytes of memory?
Thanks!!

There shouldn't be any DS1286. Are you thinking about the DS1250Y (512 kB)?

[Tantratron]

Just to confirm the EEPROM write tdsAcqEEPROMMinimalFloppyWriter does work on my TDS540C as described https://www.eevblog.com/forum/repair/attempting-repair-of-tds540c-option-1g-fail-processor/msg2997196/#msg2997196

Just some remark and caution about the sequence to properly unlock the write-protection switch versus the reboot. We need to enable the write protect but it is not clear if it should be switched off after the floppy disk stops writing. There was a repetitive reboot for ever so only choice was to turn-off the main power supply button.

[fitch]

Hello all.  Guess I am late to the party again...

I have a TDS694C and I dumped the contents from my DS1250Y and DS1486 using tdsNvramFloppyDumper.  I purchased some functional replacements with replaceable batteries from eBay.

The scope booted OK, as the seller programmed the replacements for a TDS694C, but I am unable to get the tdsNvramFloppyWriter to run to restore my original contents.  There is mention of the write protect switch.  Is this the big rocker switch at the edge of the board?  It is not near the original Dallas parts, and I can't find any documentation that identifies it.

Can someone please help me identify the switch?  And just so I get it right, I flip the switch right when the floppy light first lights at power up?

Thanks!

[ragge]

The scope booted OK, as the seller programmed the replacements for a TDS694C, but I am unable to get the tdsNvramFloppyWriter to run to restore my original contents.  There is mention of the write protect switch.  Is this the big rocker switch at the edge of the board?  It is not near the original Dallas parts, and I can't find any documentation that identifies it.

Can someone please help me identify the switch?  And just so I get it right, I flip the switch right when the floppy light first lights at power up?

Yes, it is the big rocker switch at the edge of the board. There are two small holes in the cover that allows for flipping it with the cover on using a suitable thin tool, there may be a calibration sticker covering the holes though.

Correct, you should flip it when the floppy light first lights up. If you boot the scope with the switch flipped, it will go into bootloader mode and only respond over GPIB at address 29, it will not show anything on the screen or respond to the buttons.

[james_s]

Hm I didn't touch that switch when I did the backup/restore on my TDS784C. It worked fine to back up and restore onto the new NVRAMs I installed.

[ragge]

Hm I didn't touch that switch when I did the backup/restore on my TDS784C. It worked fine to back up and restore onto the new NVRAMs I installed.

I think at least on some models, it is needed only for writing to the EEPROMs on the acquisition board. I am not sure if that is the case on all models though, some reports here indicate that it needs to be flipped also for writing to the NVRAMs.

[fitch]

Yup, hole is covered by a round cal sticker.

I am pretty sure my restore did not work.  For one, the newly programmed parts added an option 2C to my scope that I did not have before.  And, I got no status messages or anything, just the normal boot screen saying self test passed.

Guess I better dump the new ones first in case I want to keep the 2C.

[ragge]

Yup, hole is covered by a round cal sticker.

I am pretty sure my restore did not work.  For one, the newly programmed parts added an option 2C to my scope that I did not have before.  And, I got no status messages or anything, just the normal boot screen saying self test passed.

Guess I better dump the new ones first in case I want to keep the 2C.

Indeed, it is a good idea to save them just in case.
But you are likely better off with the original data to get better calibration values.
There are ways to enable options using GPIB, or the console port (needs a hardware adapter).

[fitch]

OK, flipping the switch does not change the behavior.

I get the floppy to light, then I see the Java splash screen, then the floppy gets accessed some more, but it appears to not actually do anything, it just goes to the screen that says self test passed.  If I wait, that screen clears, and waiting longer does not help.  No messages.

Tried reformatting the floppy and putting fresh files on it.  No joy.  I am afraid to try the minimal version, I would hate to scrog the scope.

Any ideas?

[ragge]

OK, flipping the switch does not change the behavior.

I get the floppy to light, then I see the Java splash screen, then the floppy gets accessed some more, but it appears to not actually do anything, it just goes to the screen that says self test passed.  If I wait, that screen clears, and waiting longer does not help.  No messages.

Tried reformatting the floppy and putting fresh files on it.  No joy.  I am afraid to try the minimal version, I would hate to scrog the scope.

Any ideas?

Are you putting the files on the top level of the floppy?

Does it work for making backups? Writing should be the same.

There should be no problem using the minimal versions, you just don't get as much feedback.

[fitch]

Yes, making backups works.

Silly question, the .jar file is only need on the PC, right?  Or do I need to put the jar file on the floppy as well?