EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: flyte on January 17, 2019, 05:48:31 pm
-
Hi all,
As many of these great Tektronix TDS scopes are ageing, they will have their NVRAMs sooner or later wiped due to battery failure and because AFAIK the only way to safely dump the NVRAMs contents is via a GPIB interface, which not every scope owner has, I've decided to write a small script which simply dumps the NVRAM contents to a floppy disk. As most TDS scopes, and certainly the higher spec'd ones, have a floppy disk option, taking a backup this way would be a quick win for anyone looking to do so or worrying about imminent battery doom.
The script is based on the JRE installer script and reads 0xA0000 bytes from the base address 0x4000000 (contiguous 128K DS1486 and 512K DS1250Y), so it should work with the TDS700C/D and TDS600C series. It has been tested on TDS754D, TDS784D and TDS694C. Adapting it to TDS series with different NVRAM addresses should be easy.
Simply put the attachment's contents into an (old) FAT formatted floppy and start up the scope with the disk mounted. About 10s after boot, it will dump the NVRAMs to dump.bin on the floppy. Use an error-free floppy and preferably first format it on the scope itself using the normal file utilities for best compatibility.
Make sure you rename the dump.bin right away to include the scope model and serial number, as there is no way to derive that from the binary dump afterwards.
Have fun saving your equipment! :)
flyte
-- EDIT/UPDATE:
If we can read this way, we can also write! ;)
So I've made a second script which will load an NVRAM dump back into the scope via floppy. Works the same way as the dumper, but expects a file writedmp.bin on the disk. Tested on a TDS754D scope, works perfectly. Note that loading a dump from a different scope will mess up all calibration values, so please be honest when offering scopes "repaired" this way and mention it to your buyer.
BTW, if you are looking for a factory new genuine Dallas DS1486, I have some left from known distributor origins. It's likely to be one of the very last batches, as the production stopped years ago and worldwide stocks are now depleted, and what now remains are Ebay floods of Asian counterfeits with all sorts of issues.
-- EDIT/UPDATE 2:
Made a new set of scripts v3, the previous download's nvram restore/write script did not write correctly in some cases which lead to a corrupt nvram, even if the file was fine, as it appeared. Also, the backup/dump script seemed to hang on A-series scopes, a TDS524A in the case tested. Please delete your old downloads, replace them with the new scripts and check info.txt in the archive.
-- EDIT/UPDATE 3:
Added a checksum verification tool so everyone can verify the dump taken has valid checksums on critical calibration data. Even though it contains checksum locations for a range of firmware versions and models, you may encounter an unrecognized NVRAM firmware prototype. Also, there may be locations in the NVRAM with other checksums than what is supported by the tool, but those verified by it are the critical ones regarding calibration and proper startup. It's written in Java, you need to install a Java JRE on your computer in order to use it. Run command example:
java -cp TDSNvrCV_1_0.zip TDSNvramChecksumVerifier DUMP.BIN
-- EDIT/UPDATE 4:
Added scripts to backup the factory calibration constants in the EEPROMs on acquisition boards of -B, -C and -D series scopes, starting with firmware v4.x. Check info.txt inside the archive. The checksum verifier has been updated to allow verification of the acquisition EEPROM dumps, and the tool will attempt to detect based on file size whether the dump is an NVRAM or acquisition EEPROM.
java -cp TDSNvrCV_2_0.zip TDSNvramChecksumVerifier DUMP.BIN
-- EDIT/UPDATE 5:
New version of the scripts which allow you to also write the EEPROMs on acquisition boards of -B, -C and -D series scopes, starting with firmware v4.x. Be very careful when using this function, you may permanently destroy your scope. Check info.txt inside the archive. The checksum verifier is now part of the archive.
-
Please leave your comment including scope model number and firmware revision for other users to know whether it worked ok.
-
To those following this thread: old release had several bugs and problems |O please update your download with the new and better release v3 available in first post 8)
-
Would it be possible to make this dump the contents of the firmware off the flash, and would this be possibly be able to restore a bricked scope? I know that the flash is already too big to be dumped all at once, when I finally did get some output over gpib it was 3MB of data, so it would have to be done over multiple reads.
-
thanks for the update @flyte
-
In theory, yes. Pratically speaking no.
Grabbing a dump in multiple files wouldn't be a big problem, but would that be useful in any way? That flash is not going to die anytime soon, the NVRAMs will. Meanwhile you can find the latest firmwares for the respective series in several places.
In order to flash, multiple problems exist. The floppy is too small, so you'd have to chop it up and make a small tool to do so automatically. Next you'd need to write a small piece of 68k flash code (similar to target.bin in tekfwtool) and somehow reboot the CPU into that instead of the VxWorks OS, or write some VxWorks compatible flash program and then hope during flashing the OS does not access it.
I think the trade-off effort vs. benefit would no longer be okay here. If you want to flash, get a GPIB interface.
The reason for making these small scripts was to allow people to easily safeguard and eventually replace their NVRAMs without buying a GPIB interface, or, worse, start opening up the scope and desolder the whole thing or even destroying it in the process of attempting to do so.
-
Here is my dump from 754C fw:5.3e modified to 784C plus added options via GPIB...
TNX!
-
An update regarding the tool:
In order for the writing script to work on several older models like the TDS524A, you should flip the calibration/write protection switch. Most firmwares refuse to boot when flipping the switch and thus the floppy disk script can't start, so you may have to flip the switch the exact moment the floppy disk light comes on for the first time, after boot. This is because part of the calibration in the NVRAM is hardware write-protected. Later models like the TDS754D have that part of the calibration stored in EEPROMs on the acquisition board, and have no NVRAM write protection.
I can confirm replacing the old DS1650Y of a TDS524 by a regular DS1250Y does work without faults. The DS1650Y only has the extra functionality to write protect certain partitions of the NVRAM. As the script does not perform any unlocking, replacing the DS1650Y with a DS1650Y (in case you'd ever manage to get an original one) might not work, if Tektronix decided to also use that partition locking feature.
In case you'd need a genuine DS1486 or DS1250Y and not the Asian counterfeits from Ebay, please P.M. me, I have some more left.
-
Hi Flyte,
Thanks a lot for developing this excellent tool. It will help many TDS owners like me.
I have a TDS540C with firmware v5.0e, with 1F, 1M, 2F option. Tried this tool which use buffer when dumping, the floppy lights 2 times during startup, but didn't start to dump when start the scope. Tried a few times, still doesn't work.
Then I tried the minimal floppy dumper, it works, and got the dump.bin on the disk. But I didn't try to use it to write back as minimal writer does not use a buffer and may cause writing problem as stated in the info.txt.
The disk quality is good as it works when using minimal dumper. So, do you think where is the problem? Maybe my scope setting need some change? Or what procedure I should follow when using the bufferred dumper?
Thanks again.
-
Upload the NVRAM dump of my TDS540C (firmware 5.0e) dump image here. Only the minimal dumper works. So don't know if this dump.bin is correct or not.
My TDS540C NVRAM chips are DS1486 and DS1650Y.
-
Hello
How you separete from the dump the contents for the ds1486 and the ds1250 for use to program the chips with a burner.Thanks
-
You can make change to the address in the startup.bat, then you can get the dump for each chip seperately. I didn't try this, but look into the startup.bat, this should work.
-
You must be the most thanked 11-post poster in the history of the EEVBLOG!
Well done!
-
Update the progress. After I got the 640K NVRAM dump (used a few disks to dump a few times, to make sure dump quality), I decided to have a try to write it back to the NVRAM. Inserted the disk into the scope and push the on button. After 2 times floppy drive lighting on, the scope restarted. Withdraw the disk immediately. The scope continued the startup process, a little different with normal startup. Finally, the familiar screen appeared, all options still there. No other different, just the time display changed to the time when this dump was made. This indicated the writing was successful. Great! I have been worrying about the NVRAM battery after I got this old TDS540C. Now, no worry!
Thanks Flyte again! Great tool!
-
Then another question is, it's said the options are stored in DS1486, address from 0x04000000 to 0x4020000, this means if I know the address, then can revise that data and use floppy to write back. No need for GPIB card and driver/software which is not very easy to play with. Right?
Anybody know the option bit address?
-
Found dxl's post on: https://www.eevblog.com/forum/testgear/hackingupgrading-old-scope-(tds754d)/msg492404/#msg492404 (https://www.eevblog.com/forum/testgear/hackingupgrading-old-scope-(tds754d)/msg492404/#msg492404)
--------------------------------------------------------------------------------------
dxl wrote:
on the TDS784D i looked at, the addresses where:
NVRAM:0400081C 0000 dc.w 0 ; 5 - TV Trig
NVRAM:0400081E 0000 dc.w 0 ; 6 - Option 1M
NVRAM:04000820 0000 dc.w 0 ; 7
NVRAM:04000822 0001 dc.w 1 ; 8 - Option 13
NVRAM:04000824 0001 dc.w 1 ; 9 - Option 1F
NVRAM:04000826 0001 dc.w 1 ; A - Option 2F
NVRAM:04000828 0000 dc.w 0 ; B
NVRAM:0400082A 0001 dc.w 1 ; C - Option 2C
NVRAM:0400082C 0000 dc.w 0 ; D - Option 3C
NVRAM:0400082E 0000 dc.w 0 ; E - Option 4C
NVRAM:04000830 0001 dc.w 1 ; F - Option 2M
Those adresses could be completely different on your scopes firmware, and i think the data has a checksum associated.
-------------------------------------------------------------------------------------------
So I used a DS1486 dump, tried to change the 0000 at address 0000082A (the dump file address start from 00000000), then floppy write back to DS1486, the 2C option didn't appear when restarted the TDS540C. Looks like I didn't find the right address?
-
Upload the DS1486 dump here, it's from TDS540C, Fv5.0e. For study and find the option bit.
-
Problem solved! The solution is 'flip the calibration/write protection switch'. As Flyte's update in this post, flip the switch when the floppy drive light for the first time; when re-starting, flip this switch back to protect position.
Using this magic, I added 2C option for my scope. Check through the COMM function buttons, all there same with the user manual stated. Thanks Flyte, again!
-
That is great! Very cool that this works. I'd thank the O.P. 10 times if I could...I love my TDS.
-
Can you post the startup file for each of the dallas chips ,I modify the startup file to ""taskSpawn ("nvramdumper",1,0x0,40800,sysExecScript,"fd0:/nvdump.app") " and I got another dump of 640 k or can you tell me how to divide the 640 k dump.
Thank you
-
@ Rollin Hand, I used the minimal dumper, as the buffer one didn't work on my scope.
For DS1486, use:
nvrBase=0x4000000
nvrSize=0x20000
For DS1650, use:
nvrBase=0x4020000
nvrSize=0x80000
Hope this can help you.
Galen
-
Galen :
it works on my tds724d without moving the protection switch .
I got 2 files with the limited dump with the ranges changed, after inspect the files with an hex editor I saw the data with options on the file the next step is to burn the 2 dallas chips .Thank you
-
Rollin,
You don't need the protection to read or dump information from the scope, only when you want to write back to it. :)
-
Hi,
Minimal dump seems to work on my TDS520B (firmware v4.1e), without moving the protection switch.
I have tried 3 times and compared the files.
I have a few differences each time.
I am assuming this is normal as they are always at about the same addresses (?)...
>fc /b "DUMP TDS520B 20190303.BIN" "DUMP TDS520B 20190303 (2).BIN"
Comparaison des fichiers DUMP TDS520B 20190303.BIN et DUMP TDS520B 20190303 (2).BIN
00000000: 18 89
00000001: 30 18
00000002: 59 31
00000004: 21 22
00000010: 02 03
0000141E: FE E2
0000141F: 9D 9F
00001AEF: E0 E2
00001AF0: 31 15
>fc /b "DUMP TDS520B 20190303 (2).BIN" "DUMP TDS520B 20190303 (3).BIN"
Comparaison des fichiers DUMP TDS520B 20190303 (2).BIN et DUMP TDS520B 20190303 (3).BIN
00000000: 89 95
00000002: 31 39
0000141E: E2 B3
0000141F: 9F 98
00001AEF: E2 DB
00001AF0: 15 E6
Michel.
-
Great to read you find it useful, I hope it'll save many scopes from the waste bin! :-+
A combined reply to various questions:
- As configured by default, the tool grabs both the contents of the DS1486 and DS1250Y in one file, as they are adjacent in memory space. The DS1486 comes first starting at dump position 0x0, then the DS1250Y starts at position 0x20000 until 0xA0000. You can simply split the file using a hex editor, no need for multiple scripts.
- I do not recommend this unless you have alternative ways to recover from failure and are sure about the backup, but for the brave who want to test whether it really works as expected and plan for the ultimate rescue action, you should write a random garbage dump of the same size to your NVRAMs first. As I said, make sure it doesn't turn into ultimate destruction ... :-BROKE :palm:. Then power up the scope, it will reboot, may hang on invalid data, but it will load default NVRAM values eventually, including a (wrong) default calibration. Then write the NVRAMs using the tool and everything should be back to normal. I tried this on a TDS754D and it worked.
- The protection switch flipping right before writing starts only seems required on older models. The D-series scopes can be written without flipping the switch.
- The structure of the dump varies with model and firmware number, but seems unchanged across major versions and equivalent hardware. E.g. TDS520D/../TDS724D/754D/784D running 7.x all have the same structure. There is a checksum over several sections in the dump, if time allows and it makes sense to do so (due to the many variants), I may write a small tool which computes the checksum, so you can be sure the dump taken is correct.
- Dumps will indeed never be the same. For a start, at position 0x0 there is the DS1486 clock which simply ticks further until the end of times. Then there is also a vast part of the NVRAM used for saving (GUI) settings and error logs, and diagnostic results. The most critical part is the section which stores calibration constants and the section configuring the hardware. All other sections may be initialized to default values without penalty to the user.
-
Definitely a great tool. And *much* easier to use than my tekfwtool i wrote long time ago! :-)
-
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.
-
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.
-
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.
-
FYI: just finished the checksum tool, see update in first post
-
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?
-
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 :palm: 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 :o
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 >:D
-
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 ... :-BROKE 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.
-
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
-
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.
-
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.
-
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)
-
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.
-
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...
-
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?
-
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.
-
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.
-
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.
-
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.
-
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,
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.
-
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.
-
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?
-
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?
-
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?
-
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.
-
Excellent - thanks a lot, flyte :-+ :)
-
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 .
-
Hi all! Can anybody send dump for TDS520b? I've bricked mine |O
-
Hi all! Can anybody send dump for TDS520b? I've bricked mine |O
Hi,
Dump for 520b is in my post.
Michel.
-
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.
-
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 (https://github.com/ragges/tektools)
Happy measuring,
Ragnar
-
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 :-DD 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
-
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 :-DD 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.
-
Kudos for this critical experiment.
No problem, due to the lack of other models, it was "only" a TDS784D, not much to loose there! :phew:
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!
-
@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.
-
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.
-
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.
-
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!!
-
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)?
-
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 (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.
-
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!
-
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.
-
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.
-
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.
-
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.
-
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).
-
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?
-
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.
-
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?
-
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?
If making backups works, you are doing it correctly. I would then suggest trying the "simple" version.
Yes, the .jar file is only for being run on a computer with Java installed, there is no use in putting it on the floppy disk.
-
Got it to work. I looked at the differences between nvwrite.app and nvdump.app. In nvdump, there was a delay at the start that was 10X the delay in nvwrite. I changed line 3 of nvwrite.app to:
taskDelay (600)
And the above worked.
Now, for my scope, I did have to flip the switch because without it, nothing changed. When I wrote the nvram with the switch flipped, my original options showed up and the date went back to the day I dumped the old ones. I had good confirmation that things were written.
And, my channel DC offsets that showed up with the new rams were gone. I am happy now.
Thanks for your help.
-
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?
I ended up using the minimal version, I couldn't get the other version to work at all, the scope seemed to just boot up normally. The minimal one worked exactly as described, I only used the NVRAM script, I didn't write the calibration eeproms.
-
I downloaded the java application ,
how do you use Checksum verifier tool under dos ?can you explain
Thanks
-
A great tool. Thank you.
Help sought:
Attempting to dump NVRAM and EEPROM data from a real TDS784D 'scope before the NVRAM fails (no sign of that seen yet)
Firmware shows 'FV: v6.6e'
Process:
Take floppy and run dosfsck check on it. Shows clean (I think this will check for bad clusters)
Format floppy in 'scope
Copy startup.bat and dumpall.app from 'tdsNvramFloppyTool-extra' to floppy
Turn off all traces and stop triggering on 'scope
Insert floppy into 'scope and cycle power.
Once finished move floppy to PC.
Then check the checksums.
EEPROM data checksum is OK but even after 4 attempts the NVRAM checksum fails.
Using this command:
java -cp TDSNvrCV_2_1.jar TDSNvramChecksumVerifier NVRAM.BIN
Attached are the output of TDSNvramChecksumVerifier and NVRAM.BIN
Maybe this is all because I have a Firmware version that hasn't been seen here before in which case maybe the attached file is of value?
In which case I assume that I shouldn;t be worried about the checksum failure.
Remove the .txt suffix.
Sorry to be verbose. I am trying for efficiency.
Thank you in advance for any constructive comments.
-
Quote from: EngelenH on 2020-02-19, 14:37:01 (https://www.eevblog.com/forum/index.php?topic=164074.msg2928086#msg2928086)
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.
Yes, it works with a slight issue.
To elaborate: The only adapter I could find that fits into the scope and has the correct connector is the Gotek SFR1M44-DU26/-TU26 (DU/TU specify the location/orientation of the connector, I've got the DU26 in my TDS784D). This one has NO LED display and works a bit different compared to the other Goteks (with original firmware).
It has an internal memory of 1.44MB, so even without any USB stick plugged, the scope will see a floppy and can write/read to/from it. (However, everything written to it can't be copied to the "outside world". See below.)
There are 2 buttons and a LED on the front. The layout is like this: [-USB-] [LED] [BTNOUT] [BTNIN] GOTEK
The USB stick has to be formatted in FAT32 and 1GB or larger. No special file format is needed. No *.img floppy images or anything. Just normal files.
Now if you plug such USB stick, the Gotek will empty the internal floppy image and copy the first few file(s) from the USB into it until it's full (1.44MB). These files will show up on the scope even if you remove the USB. If you need different files, you can press BTNIN to copy the next max. 1.44MB of files - repeat until you see the files you want.
If the scope writes anything at this point, it goes into the internal memory of the Gotek. To get files ONTO the USB, you will have to enable "OUT" mode on the Gotek first by pushing BTNOUT. The LED on the Gotek will light up constantly. However, this will empty the internal floppy image, so the scope will see an empty floppy at that moment. But every new file written by the scope goes right onto the USB drive (files already on the USB won't be touched). Once finished, press BTNOUT again to unmount/eject the USB (LED turns off) to be able to remove it.
So to get a dump file, you'll have to plug the USB (with only the dump app on it - it will automatically be copied into the internal floppy of the Gotek and visible on the scope), run the Application and in the 6 seconds the application waits before it starts dumping, press BTNOUT to enable writing to USB (Gotek-LED turns on). The app should start dumping, but once finished, since the scope can't continue reading the app now (from the scope's view the file is "gone"), it will hang at "dump to floppy started, please wait". So just wait for like 10 minutes which should be more than enough, then press BTNOUT until the LED turns off and switch off the scope. You should find the DUMP.BIN on your USB now.
-
Quote from: Galen on 2019-03-02, 07:15:22 (https://www.eevblog.com/forum/index.php?topic=164074.msg2235711#msg2235711)
Problem solved! The solution is 'flip the calibration/write protection switch'. As Flyte's update in this post, flip the switch when the floppy drive light for the first time; when re-starting, flip this switch back to protect position.
Using this magic, I added 2C option for my scope. Check through the COMM function buttons, all there same with the user manual stated. Thanks Flyte, again!
Note: You can also run the APP file manually after boot. So without the floppy inserted, boot the scope normally. Insert floppy, press SETUP, choose the APP, flip switch if you're attempting to write, run APP, done.
Also: Instead of writing the whole NVRAM dump back with the risk of things going REALLY wrong due to a bad floppy or so, why not have a look at the app script and noticing that GpibInput() is the same as sending commands via GPIB ... so you can send the famous password followed by "that ATPUT command" to flip the bits. Much safer than risking a bad NVRAM (if your memory addresses are correct).
-
Finally got around to picking up a USB floppy drive for my laptop, so I figured I'd better get cracking and back up the NVRAM and EEPROM data from my TDS754D FW V6.3e (upgraded to 784, like many here). Both dumps worked flawlessly, checksum verifier gave them the a-ok. I opened the NVRAM dump in HxD and verified that my factory options were correct, they were fine. Then I decided to add 2C for the heck of it. Flipped the byte at the correct address and tried to write. No dice without flipping the protect switch. Tried again, this time flipped the switch right before the write operation and flipped it back before reboot. All good now. Before and after splash screens below.
-
I just replaced the defective EEPROMS in the acquisition board in my TDS754D(firmware 7.2e)--does anyone have a copy of their cal for this firmware? Was getting 250nv storage too small errors (plus much more) before replacing the EEPROMS, now just Libs with crcc failures and extended cal librarian reset--I assume it will go away with a calibration.
Yes, I realize I need a cal but I want to see a successful boot before I spend $$ on a suitable signal generator (I do have the cal software running on an ancient PC). Currently the EEPROMS are all set to the default of all 1s.
Thanks, David
-
I just replaced the defective EEPROMS in the acquisition board in my TDS754D(firmware 7.2e)--does anyone have a copy of their cal for this firmware? Was getting 250nv storage too small errors (plus much more) before replacing the EEPROMS, now just Libs with crcc failures and extended cal librarian reset--I assume it will go away with a calibration.
Yes, I realize I need a cal but I want to see a successful boot before I spend $$ on a suitable signal generator (I do have the cal software running on an ancient PC). Currently the EEPROMS are all set to the default of all 1s.
Thanks, David
Hi David,
I was in similar failure and situation as yourself, you might try this specific method I've done requiring an arduino https://www.eevblog.com/forum/repair/attempting-repair-eeprom-voltage-increase-method/msg3011456/#msg3011456 (https://www.eevblog.com/forum/repair/attempting-repair-eeprom-voltage-increase-method/msg3011456/#msg3011456)
In my case, one EEPROM was partially failed which would flag the ASIC unable to read hence 250nv error. Once I recovered both EEPROM's content, I re-loaded the HEX file thanks to Floppy method.
Good luck, Albert
-
Quote from: EngelenH on 2020-02-19, 14:37:01 (https://www.eevblog.com/forum/index.php?topic=164074.msg2928086#msg2928086)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.
Yes, it works with a slight issue.
To elaborate: The only adapter I could find that fits into the scope and has the correct connector is the Gotek SFR1M44-DU26/-TU26 (DU/TU specify the location/orientation of the connector, I've got the DU26 in my TDS784D). This one has NO LED display and works a bit different compared to the other Goteks (with original firmware).
It has an internal memory of 1.44MB, so even without any USB stick plugged, the scope will see a floppy and can write/read to/from it. (However, everything written to it can't be copied to the "outside world". See below.)
There are 2 buttons and a LED on the front. The layout is like this: [-USB-] [LED] [BTNOUT] [BTNIN] GOTEK
The USB stick has to be formatted in FAT32 and 1GB or larger. No special file format is needed. No *.img floppy images or anything. Just normal files.
Now if you plug such USB stick, the Gotek will empty the internal floppy image and copy the first few file(s) from the USB into it until it's full (1.44MB). These files will show up on the scope even if you remove the USB. If you need different files, you can press BTNIN to copy the next max. 1.44MB of files - repeat until you see the files you want.
If the scope writes anything at this point, it goes into the internal memory of the Gotek. To get files ONTO the USB, you will have to enable "OUT" mode on the Gotek first by pushing BTNOUT. The LED on the Gotek will light up constantly. However, this will empty the internal floppy image, so the scope will see an empty floppy at that moment. But every new file written by the scope goes right onto the USB drive (files already on the USB won't be touched). Once finished, press BTNOUT again to unmount/eject the USB (LED turns off) to be able to remove it.
So to get a dump file, you'll have to plug the USB (with only the dump app on it - it will automatically be copied into the internal floppy of the Gotek and visible on the scope), run the Application and in the 6 seconds the application waits before it starts dumping, press BTNOUT to enable writing to USB (Gotek-LED turns on). The app should start dumping, but once finished, since the scope can't continue reading the app now (from the scope's view the file is "gone"), it will hang at "dump to floppy started, please wait". So just wait for like 10 minutes which should be more than enough, then press BTNOUT until the LED turns off and switch off the scope. You should find the DUMP.BIN on your USB now.
I'm not sure to fully understand how to use this GOTEK, the role of each button and the sequence of plug, remove...
So far, I've only installed the BAT executable called tdsAcqEEPROMMinimalFloppyDumper which aims to make a local copy of EEPROM. The toogle switch of my TDS784D is OFF so no risk of bricking anything if something went wrong with the GOTEK. The Gotek was plug in on the USB then I start the TDS784D then will go to then press SETUP to finally display the content (FILE UTILITIES).
As you can see on the attached picture, the initial empty USB-floppy emulation does contain the EEPROM.BIN but I do not understand what I need to do in order to have it copy in the GOTEK then read later on my computer ?
The GOTEK in my TDS784D has two press buttons but no idea how to use them.
Thank you, Albert
-
Following my previous post where I notice actually that once the USB stick is removed, the TDS is power OFF then later or next day power ON, the Gotek seems to store and keep its last content, the DUMPING application as well as the EEPROM.BIN file, see attached picture.
Does anyone knows how I can have the GOTEK emulator content copied locally to my USB stick ?
-
Quote from: Tantratron on Today at 01:21:29 (https://www.eevblog.com/forum/index.php?topic=164074.msg3349558#msg3349558)Does anyone knows how I can have the GOTEK emulator content copied locally to my USB stick ?
Did you not read my big blob of text where I explain how these type of GOTEKs work?
-
Did you not read my big blob of text where I explain how these type of GOTEKs work?
Yes I have in the last 2 days but in my case, it does not work per your instructions so maybe my GOTEK has not the same part number or internal jumpers set similar to yours.
-
Quote from: Tantratron on Today at 01:36:46 (https://www.eevblog.com/forum/index.php?topic=164074.msg3349572#msg3349572)
>Quote from: mbirth on Today at 01:28:45 (https://www.eevblog.com/forum/index.php?topic=164074.msg3349566#msg3349566)Did you not read my big blob of text where I explain how these type of GOTEKs work?
Yes I have in the last 2 days but in my case, it does not work per your instructions so maybe my GOTEK has not the same part number or internal jumpers set similar to yours.
Are you sure? The button next to the USB port and LED should be the "OUT" button. With a USB stick attached pressing that button, the LED should light up constantly. Any file written during this time should end up on the USB stick. After writing files (e.g. a screenshot), press that button again so the LED turns off. Then you can remove the USB drive and should find the new file on there.
Maybe your buttons are swapped, though. But you can easily test this - if the LED lights up constantly after pressing a button, that's the BTNOUT.
-
Are you sure? The button next to the USB port and LED should be the "OUT" button. With a USB stick attached pressing that button, the LED should light up constantly. Any file written during this time should end up on the USB stick. After writing files (e.g. a screenshot), press that button again so the LED turns off. Then you can remove the USB drive and should find the new file on there.
Maybe your buttons are swapped, though. But you can easily test this - if the LED lights up constantly after pressing a button, that's the BTNOUT.
I've done different combinations, tests without any success so far.
However I do confirm that once pressing the OUT button (close to USB connector),a blue LED will come up and stay then if pressing again, it will disappear. The behavior of the IN button is different, the blue LED will come then after few seconds will automatically disappear.
Could you just re-confirm exactly the time sequence of insert, button push in your case.
What I've done so far, first the EEPROM dumping application is copied on my USB stick. I insert the stick in the TDS then turn ON the TDS which will boot. Once booting is complete, as you saw on my previous screen shots, the emulated of Floppy does contain the application and its output, namely the EEPROM.BIN
At what precise moment do you press the OUT button to have the result being copied in the stick ?
Thank again for your patience, Albert
-
Quote from: Tantratron on Today at 02:04:00 (https://www.eevblog.com/forum/index.php?topic=164074.msg3349590#msg3349590)
However I do confirm that once pressing the OUT button (close to USB connector),a blue LED will come up and stay then if pressing again, it will disappear. The behavior of the IN button is different, the blue LED will come then after few seconds will automatically disappear.
Yes, that's exactly the same behaviour I'm seeing with my device. The OUT button activates the USB drive for output. As long as the LED is lit, all files saved to the "floppy" end up on the USB. When pressing OUT again, the USB drive is ejected and all files written to floppy then end up in the internal memory area of the GOTEK again (from which they can never be copied to USB).
Pressing IN reads the files from the USB and copies them into the internal memory area of the GOTEK. That's why you see the blue LED only lighting up for a short time. Once the files are copied, the LED turns off again. If you have more than 1.44MB of files on the USB, you can press the IN button again to copy the next few files into the internal memory area (removing the previously copied files from there).
Quote from: Tantratron on Today at 02:04:00 (https://www.eevblog.com/forum/index.php?topic=164074.msg3349590#msg3349590)
Could you just re-confirm exactly the time sequence of insert, button push in your case.
At what precise moment do you press the OUT button to have the result being copied in the stick ?
- Instead of the MinimalFloppyDumper, copy only the acqedump.app from tdsAcqEEPROMFloppyDumper to your USB
- Plug USB with the dump script on it
- Press IN once to copy the script into the internal memory area and make it available to the scope
- On the scope, go to SETUP --> Select Application, navigate to the floppy and the correct file (ACQEDUMP.APP) and prepare to press Activate Application
- Put a finger on the OUT button on the GOTEK
- Press "Activate Application" and wait for 2-3 seconds, then press the OUT button (the application has a 6 seconds delay after startup), LED should light up constantly on the GOTEK
- Wait about 5-10 minutes - that should be more than enough for the dump to be written. (Since the GOTEK is now in "OUT" mode, the scope can't read the rest of the APP file, so the dumper tool will just hang after dumping and you won't know when it's finished.)
- Press OUT on the GOTEK so it ejects the USB. Once the LED turns off, remove the USB and check on your PC if you can find the dump on it. Power cycle the scope or abort the running App to get out of the waiting screen.
If you don't find the output file (ACQEEPRM.BIN) on your USB drive, repeat the process and maybe experiment with some of the timings. E.g. wait a bit longer after pressing "Activate Application" before pressing "OUT" on the GOTEK. Or wait a bit longer before you eject the USB.
-
Quote from: Tantratron on Today at 02:04:00 (https://www.eevblog.com/forum/index.php?topic=164074.msg3349590#msg3349590)
Could you just re-confirm exactly the time sequence of insert, button push in your case.
At what precise moment do you press the OUT button to have the result being copied in the stick ?
- Instead of the MinimalFloppyDumper, copy only the acqedump.app from tdsAcqEEPROMFloppyDumper to your USB
- Plug USB with the dump script on it
- Press IN once to copy the script into the internal memory area and make it available to the scope
- On the scope, go to SETUP --> Select Application, navigate to the floppy and the correct file (ACQEDUMP.APP) and prepare to press Activate Application
- Put a finger on the OUT button on the GOTEK
- Press "Activate Application" and wait for 2-3 seconds, then press the OUT button (the application has a 6 seconds delay after startup), LED should light up constantly on the GOTEK
- Wait about 5-10 minutes - that should be more than enough for the dump to be written. (Since the GOTEK is now in "OUT" mode, the scope can't read the rest of the APP file, so the dumper tool will just hang after dumping and you won't know when it's finished.)
- Press OUT on the GOTEK so it ejects the USB. Once the LED turns off, remove the USB and check on your PC if you can find the dump on it. Power cycle the scope or abort the running App to get out of the waiting screen.
If you don't find the output file (ACQEEPRM.BIN) on your USB drive, repeat the process and maybe experiment with some of the timings. E.g. wait a bit longer after pressing "Activate Application" before pressing "OUT" on the GOTEK. Or wait a bit longer before you eject the USB.
Many thanks @mbirth, I've done as you explained above and it worked fine now. In fact I did not wait 5-10min but only say 1min then put the USB stick ito my MacBook Air.
So it seems the trick is to kind of know blindly or by time guess what status the APP or the BAT is running to then force the OUT on the Gotek.
Again thank you so much...
Have you done the same with Gotek where this is time to WRITE the EEPROM.BIN into the 2 real I2C eeprom soldered on the acquisition board ?
I did this few months ago with real floppy drive to repair the University TDS540C, it worked great where of course, it is risky since we need to enable the protection switch.
Just curious if you have done successfully with the Gotek and what was your presse-release sequence ?
Albert
-
Quote from: Tantratron on Today at 05:59:20 (https://www.eevblog.com/forum/index.php?topic=164074.msg3349834#msg3349834)
Have you done the same with Gotek where this is time to WRITE the EEPROM.BIN into the 2 real I2C eeprom soldered on the acquisition board ?
I did this few months ago with real floppy drive to repair the University TDS540C, it worked great where of course, it is risky since we need to enable the protection switch.
Just curious if you have done successfully with the Gotek and what was your presse-release sequence ?
Glad it worked out! :)
The other way around is wayyyy easier. Just put the files you want to flash onto the USB, insert it into the GOTEK, press the "IN" button so all files should pop up on the internal memory area. Then you can remove the USB and consider the "floppy" inserted. So if you restart the scope, it will run STARTUP.BAT and do the flashing. Once you don't want it to flash again upon startup, you can connect the USB and press OUT, wait a bit, press it again and the internal memory area should be blank again.
Although I must admit apart from using a script to issue a few GPIB-commands to unlock features, I didn't flash anything yet.
-
Hi I have a tds 644a I think the nvram may be failing will your program help me to back up the nvram and when I replace the chip reinstall the nvram image, I have not tried any thing like this I can replace the chip OK if I can get one, I just need some help with the back up and restore, please help, ps I do not have a prgramer
-
Firstly thanks for these tools - very impressive!
I've just acquired a Tek TDS744 (FW 1.0e, ser B010126) with a few issues - mostly noise on channel 2.
Before I attempt repair I thought it would be a good idea to do a backup of the NVRAM and EEPROM in case of failure later. The 'minimal' versions of the tools seem to have taken valid images of the NVRAM and EEPROM. However, when I run the checksum verifier on the NVRAM it doesn't seem like it's able to cope with the specifics of the TDS744:
Detected large file, considering dump an NVRAM dump
NO prototype match found for dump data, listing all interpretations known by this tool:
Interpretation of dump data as a firmware TDS524A-v3.8.7e based dump :
dump section=EXTCONST address=0x8ce size=0xfa checksum=INVALID (actual=0x5796 computed=0x39bf)
dump section=INTCONST address=0x1420 size=0x380 checksum=INVALID (actual=0x5f53 computed=0x986d)
dump section=STATE address=0x19fc size=0x716 checksum=INVALID (actual=0x41b8 computed=0xb896)
dump section=ENVIRONMENT address=0x1038 size=0x12c checksum=OK (actual=0x5c2e computed=0x5c2e)
dump section=DIAG address=0x1006 size=0x14 checksum=OK (actual=0x2c8 computed=0x2c8)
dump section=HWACCOUNTANT address=0x806 size=0x32 checksum=OK (actual=0x79 computed=0x79)
Interpretation of dump data as a firmware NVRAM-TDS684B-v4.3e based dump :
dump section=INTCONST address=0x1420 size=0x5d2 checksum=INVALID (actual=0x5f53 computed=0xd9f5)
dump section=STATE address=0x19fc size=0x9be checksum=INVALID (actual=0x41b8 computed=0xf605)
dump section=ENVIRONMENT address=0x1038 size=0x12c checksum=OK (actual=0x5c2e computed=0x5c2e)
dump section=DIAG address=0x1006 size=0x14 checksum=OK (actual=0x2c8 computed=0x2c8)
dump section=HWACCOUNTANT address=0x806 size=0x32 checksum=OK (actual=0x79 computed=0x79)
Interpretation of dump data as a firmware NVRAM-TDS784C-v5.2e based dump :
dump section=INTCONST address=0x2c20 size=0x70e checksum=INVALID (actual=0x0 computed=0xe1ee)
dump section=STATE address=0x33f0 size=0x11e4 checksum=INVALID (actual=0x0 computed=0x7d9c)
dump section=ENVIRONMENT address=0x2838 size=0x12c checksum=INVALID (actual=0x6400 computed=0x2926)
dump section=DIAG address=0x2806 size=0x14 checksum=INVALID (actual=0x3200 computed=0xea00)
dump section=HWACCOUNTANT address=0x806 size=0x32 checksum=OK (actual=0x79 computed=0x79)
Interpretation of dump data as a firmware NVRAM-TDS694C-v6.4e based dump :
dump section=INTCONST address=0x2c20 size=0x10b2 checksum=INVALID (actual=0x0 computed=0xfd35)
dump section=STATE address=0x3db4 size=0x9be checksum=INVALID (actual=0x0 computed=0x8250)
dump section=ENVIRONMENT address=0x2838 size=0x130 checksum=INVALID (actual=0x6400 computed=0x2c26)
dump section=DIAG address=0x2806 size=0x14 checksum=INVALID (actual=0x3200 computed=0xea00)
dump section=HWACCOUNTANT address=0x806 size=0x32 checksum=OK (actual=0x79 computed=0x79)
Interpretation of dump data as a firmware NVRAM-TDS784D-v7.4e based dump :
dump section=PFCAL address=0x1002 size=0x17fc checksum=INVALID (actual=0x6555 computed=0xf384)
dump section=INTCONST address=0x2c20 size=0x21aa checksum=INVALID (actual=0x0 computed=0x27b4)
dump section=STATE address=0x5330 size=0x11e4 checksum=INVALID (actual=0x6502 computed=0x2e7c)
dump section=ENVIRONMENT address=0x2838 size=0x12c checksum=INVALID (actual=0x6400 computed=0x2926)
dump section=DIAG address=0x2806 size=0x14 checksum=INVALID (actual=0x3200 computed=0xea00)
dump section=HWACCOUNTANT address=0x806 size=0x32 checksum=OK (actual=0x79 computed=0x79)
I'm just a bit paranoid that I haven't got a good capture of the NVRAM - is there any way to tell?
I have attached a ZIP with the two dumps
-
Firstly thanks for these tools - very impressive!
I've just acquired a Tek TDS744 (FW 1.0e, ser B010126) with a few issues - mostly noise on channel 2.
Before I attempt repair I thought it would be a good idea to do a backup of the NVRAM and EEPROM in case of failure later. The 'minimal' versions of the tools seem to have taken valid images of the NVRAM and EEPROM. However, when I run the checksum verifier on the NVRAM it doesn't seem like it's able to cope with the specifics of the TDS744:
I've restored and hacked few TDSxxx/C/D where my advice is to rather program a valid NVRAM content provided by a donor into your new NVRAM.
In the past, I did loose huge time the hard way thinking copy of NVRAM's from a partial bit rot NVRAM to be the way. It will brick your scope or create partial strange anomalies. The failure of the battery or the NVRAM's content is progressive, depends where in the memory, what it stores as critical.
Dumping the EEPROM is very OK, easy and recommended since it is PROM plus calibrated only into your specific acquisition board local defects but NVRAMs can be a nightmare but easy to clone from other valid TDS.
Albert
-
There is an exact functional replacement for the NV devices on eBay for the TDS700x, TDS600x, or TDS500x. Seller kellyjo_13 designed and fabricates these devices with replaceable batteries, and includes sockets for $100 for the TDS700x/600x, and $50 for the TDS500x. As for the TDS500x DS1650Y, it is pin compatible with the DS1250Y, but you might contact him/her, as he/she is quite helpful. The listings are at: https://www.ebay.com/itm/302913384290. (https://www.ebay.com/itm/302913384290.) for the TDS700x/600x, or: https://www.ebay.com/itm/293843458213 (https://www.ebay.com/itm/293843458213) for the TDS500x.
With my TDS784C, the batteries were still viable, and I was able to remove the Dallas parts, and read them with my TL866II, and program the kellyjo devices. They have been in place since early 2019, and are working just fine.
-
On my early (S/N: B010511) TDS784C, the scripts did not work on firmware version 5.0e, but when I upgraded the firmware to 5.2e via GPIB as in the link below, now the scripts work fine.
https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918 (https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918)
-
Hello Flyte,
How are you?
As I bought recently a TDC 754C, I am very interested in your artikel about saving data. You write: "Simply put the attachment's contents into an (old) FAT formatted floppy and start up the scope with
the disk mounted." Where can iI find the attachment??
Thank You for Your reply,
Ton, PA3BMI
-
Tools and info are attached to the 1st post of this thread. Apologies, I haven't been very active here over the past year ...
-
Thanks for the tool! I went ahead and dumped my 744A-v4.0e, attached are the eeprom and nvram if that's wanted since I noticed there was no firmware for NVRAM-TDS744A* in the interpretation of dump data.
-
Thanks for the tool! I went ahead and dumped my 744A-v4.0e, attached are the eeprom and nvram if that's wanted since I noticed there was no firmware for NVRAM-TDS744A* in the interpretation of dump data.
If you have a GPIB adapter to your PC, could you have a go at extracting the firmware? I haven't got V4.0 in my library of firmwares yet. :)
The process is easy as shown in this thread:
https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918 (https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918)
Just go to step 9, unless you want to go ahead and update your firmware to 4.2.1e :)
https://w140.com/tekwiki/wiki/TDS744A (https://w140.com/tekwiki/wiki/TDS744A)
-
If you have a GPIB adapter to your PC, could you have a go at extracting the firmware? I haven't got V4.0 in my library of firmwares yet. :)
The process is easy as shown in this thread:
https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918 (https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918)
Just go to step 9, unless you want to go ahead and update your firmware to 4.2.1e :)
https://w140.com/tekwiki/wiki/TDS744A (https://w140.com/tekwiki/wiki/TDS744A)
The only GPIB adapter I have as a Prologix clone, so using the tektools will require some work from what I have read (basically re-write function calls to be compatible with Prologix and recompile).
As a note, after seeing your profile, despite being from the States I am actually currently Tokyo based. I can likely lug the scope to the Hackerspace with a laptop at some point and see if anyone has a Keysight/Agilient/NI USB/GPIB adapter.
-
The only GPIB adapter I have as a Prologix clone, so using the tektools will require some work from what I have read (basically re-write function calls to be compatible with Prologix and recompile).
Hmm, I'm not sure about that sort of stuff, I program with solder so I won't be much help. :D
As a note, after seeing your profile, despite being from the States I am actually currently Tokyo based. I can likely lug the scope to the Hackerspace with a laptop at some point and see if anyone has a Keysight/Agilient/NI USB/GPIB adapter.
Oh cool! I'm out Chiba way but travel in to Otemachi each day for work.
If you need spare parts, I have some bits so feel free to ask and I'll see what I've got.
Also, if you need replacement relays for your input hybrids (They are a known wear point in these scopes, you'll know when your scope fails SPC), here's the easiest and relatively cheap place to get them:
https://eleshop.jp/shop/g/g419133/
-
I just got a TDS754A from Ebay and would like to replace the NVRAM chips. For backup and options acitivating I have a GPIB adapter in the mail but I could try this floppy dump tool now. Just one question: since I have an A-version would the tool work with it? I will get new replacements from ebay, not original but better.
-
Hi everybody, and flyte specially.
I am trying to do a FDD dump of the NVRAM and nothing happens...silly me, maybe. I formatted a FDD in the scope itself (TDS 784A), in FAT, as requested. Then, I extracted all files from the zip archive and copied inside this FDD via LaCie external FDD and a PC (I copied everything but the README file). I started the scope, tried to do it without and with toggling the protection SW off...and nothing. The scope starts as ever (after ages, BTW, in spite all the DIP switches are in the OFF position). All tests are OK. But I am afraid of losing data.
If I go to file utils, I will be able to see all the FDD contents, but I can't execute anything (I will put a pic here).
Help!. Am doing something wrong, for sure. Could somebody be of any help for me?. TIA!!!!!
EDIT: Sorry...INFO is also copied.. |O
-
Try putting the actual single utility you want to use one at a time on the disk, directly in the root directory (i.e. not in a folder).
Also, if you have an older firmware on your scope, you might have to update it. I found this to be the case with my TDS784C.
Let us know if it works, it might provide the answer to Pete2. :)
-
Hello my friend, and again, thanks a lot!. I’ve done it (first thing was put the contents of the folder to do a full dump), and it didn’t worked.
Maybe I need to update the FW. I’ll prefer to do it over an empty EPROM (JIC…). I didn’t look at the type and model of EPROM, but I remember I have one of these programmers (I understand that the latest FW is available in TekWiki).
Anyway, I’ll keep you well informed.
Thank you!!
-
Hello again,
I am having problems trying to dump the cal data in a FDD. I am very sure that, as TERRA Operative told, this is related to the scope's FW. The scope is a Tek TDS784A, and I have a FW version 4.1e. I readed here in the forum that somebody has a newer version of the FW for this scope, but I am not able to find it out over the internet. Could somebody post a link to download it?. And if so, (specially for TERRA Operative): do you think it will be a bin file which I can "burn" over an empty UV erasable EPROM (in order to preserve the actual one)?.
Also, I did not have a GPIB to USB converter. I think it will be a good idea to order one (it comes from China, and it takes a long time to arrive here to Spain). Does somebody of you have a favourite one: NI, Agilent...or all of them works fine?.
Thanks a zillion in advance for you invaluable help.
-
Ola Fichamba,
The issue which you describe could be related eventually to these 2 topics
https://www.eevblog.com/forum/repair/tek-tds-744a784a-fws-nvlibrariansdiag-libs-with-crcc-failures-extconst/ (https://www.eevblog.com/forum/repair/tek-tds-744a784a-fws-nvlibrariansdiag-libs-with-crcc-failures-extconst/)
https://www.eevblog.com/forum/testgear/conversion-of-500mhz-tds744a-to-1ghz-tds784a/msg4859078/#msg4859078 (https://www.eevblog.com/forum/testgear/conversion-of-500mhz-tds744a-to-1ghz-tds784a/msg4859078/#msg4859078)
Regarding the GPIB-USB interface, my own experience to repair TDSxxx's prefers NI product made in Europe to avoid issues. If you like, my company has few spare to sell from France, these are legit made in Hungary so will not suffer from chinese copy-cat detected then blocked by NI driver.
Buenas tardes, Albert
-
Hello again,
I am having problems trying to dump the cal data in a FDD. I am very sure that, as TERRA Operative told, this is related to the scope's FW. The scope is a Tek TDS784A, and I have a FW version 4.1e. I readed here in the forum that somebody has a newer version of the FW for this scope, but I am not able to find it out over the internet. Could somebody post a link to download it?. And if so, (specially for TERRA Operative): do you think it will be a bin file which I can "burn" over an empty UV erasable EPROM (in order to preserve the actual one)?.
Also, I did not have a GPIB to USB converter. I think it will be a good idea to order one (it comes from China, and it takes a long time to arrive here to Spain). Does somebody of you have a favourite one: NI, Agilent...or all of them works fine?.
Thanks a zillion in advance for you invaluable help.
Unfortunately I don't have a copy of any of the TDS784A firmware versions (but if you extract your firmware and NVRAM, please send it to me and I'll add it to the Tekwiki! :) )
There is an amount of cross compatibility between scope models, so you might be able to say use v4.2.1e firmware for the TDS744A (https://w140.com/tekwiki/wiki/TDS744) and it might work.
If you copy out your existing firmware first, you can always try... If it doesn't work, you can just copy the original firmware back in again and the scope will work again just fine.
If you do the experiment, let me know so I can update my notes and the tekwiki. :)
The UV EPROM (I believe) is just the boot ROM or similar and not the actual firmware. The firmware is in the Dallas NVRAM chips (the bigger black box(es) ) and is downloaded and updated etc via GPIB.
There is a utility and instructions here:
https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918 (https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg3758918/#msg3758918)
Alternatively, if you are replacing the NVRAM's with replacements (old backup batteries are ooollddd) you could just directly copy out the entire contents of the chips with a chip programmer and copy back into the new NVRAM's.
As for USB to GPIB adapters, I use an ebay sourced Agilent 82357B and install the Keysight iolibsuite as described in the link above and it 'just works'.
-
Thanks a lot for your help and comments. I was ill. Now I am good, but...HEEELP! HEEEELP!!!!.
It seems that I have erased the data inside the Dallas Watchdog timer chip. I wanted to try my dexterity with the Dremel, and everything went well. I found a couple of 3V batteries inside (one of them with 2.9V, and the another with 2.7V...no need to change, but...lithium, ya know...suddenly zero...or very close to). The thing is I am sure I did not damage any internal part. But I am sure that I disconnect one of the batteries with the Dremel (the negative pin) before applying new battery (a 2,300 mA one...). The secondary battery was fine, untouched and connected (I mean here the one which is deeper, the one which is mounted farther from the pin #1).
I socketed the 3 main ICs (EPROM and the two Dallas chips). I have do it so to buy a programmer and extract its contents, specially for TERRA Operative (he told me so). I tested the scope with the new sockets and it worked as ever. Perfect, no problems at all. BUT when I make the change of batteries in the Dallas DS1486-120 chip, connected to the socket in the scope, and turned it on...everything seems fine (video tests on screen, relay clicks, etc.), the scope is stuck in the clock!!!. I am not able to boot it up again!!! |O and I cutted the negative from the second battery once I connected the new one (see pic).
So...what can I do?. Of course, it seems to be very clear that my problem is in the above mentioned Dallas chip (I thought it has no data inside, only realtime clock), but obviously it had data.
BTW, please tell me what programmer I can buy to work with these chips, and also to extract the data from the EPROM, and the program to work with it (maybe the programmer comes with one).
Please, I need your help. I know that I will have it.
Here are some pics of the results. I needed to connect both positive terminals of both batteries, because connecting the new one to the one closest to pin #1 does not make that the second battery inside the Dallas to have voltage (maybe a diode between the two?...if so, I did not use a diode...hope this will help).
Thank you all.
-
The common TL866II chip programmer made by XGecu, or their latest version thereof, will read and write these chips. It is a well priced bit of gear that works on a huge number of chips so is good to keep in the tool kit.
It also has a lot of community support here on EEVBlog forums and elsewhere on the internet, so if you have troubles, someone is likely to be able to help.
I have one and it works well. I just programmed a new replacement DS1245Y NVRAM last night (you can get this part number new from Digikey etc) that I read out from the old chip for a TDS540 I am currently restoring.
The two batteries are connected to a management chip such that (I believe....) it will use one battery until it is depleted and then switch to the other battery, maybe with some charge balancing logic too maybe.
If you cut the trace to the good battery and left the flat battery connected, you may have lost your data... :(
One of those two NVRAM chips stores user waveform data etc so no big deal if it's lost, but the watchdog chip is where the firmware is stored IIRC. Empty chip = no boot... :(
However, many of these scopes share the same firmware across models, with the specific model defined by the placement of a few resistors on the acquisition board (The big one on the bottom of the scope).
So, you could very well be able to revive your scope by installing some firmware from a similar scope of a similar revision.
I would try using a firmware image with the same major revision number (i.e. your firmware is v4.1e, so stick with v4.xxxxx firmwares) from another TDS700 series scope (https://w140.com/tekwiki/wiki/TDS700) and see what happens, just try one firmware after another until the scope boots and works ok.
The v4.2.1e firmware from the TDS744A (https://w140.com/tekwiki/wiki/TDS744) is a good bet.
Using the wrong firmware won't damage the scope, it just won't boot properly or it will throw a bunch of errors, in that case just pull the NVRAM out and reprogram with another firmware until you have joy.
-
Thanks a lot, my friend. So, is it not a problem to flash the watchdog timer of one scope model with the .bin file of another one of the same series (the 744 in this particular case)?. I need to do it extracting the watchdog timer from its socket and using the recommended programmer, not via GPIB. Moreover, I saw Digikey has enough ICs to replace the Dallas DS1486-120 (the one you mention in previous post, 12xx, I can't remember). It costs about US$ 32 or so, just in case.
My first need is to put the scope back in service again. But in spite I saw the DIP switches all in the OFF position (including the one for selftest during startup), it taked a loooong time to startup. Maybe there's a logic IC after the DIP which is not working correctly, and it didn't change the seltest to OFF, even if the DIP switch is OFF. But this is another story. I really need the scope working, even as before :palm:
Cheers!
-
Yep, go wild with trying different firmwares (under the guidelines I said re. versions) until one works.
With a programmer is much faster and easier than via GPIB (assuming your NVRAM is now socketed)
Once it's actually booting properly, then worry about and chase the other issues.
-
Hello again:
The zip file in TekWiki (4.2.1e) has 1 bin file inside (only one; maybe it is for the Dallas DS1650Y-100). The one I need is for the watchdog timer (Dallas DS1486-120). The FW version of my TDS784A is 4.1e. The options are 13 1F 1M and 2F. Does somebody has something in .bin for this watchdog chip, or must I checkit -as TERRA Operative say- with several versions of the 744 until one works?.
Thanks again for your help.
-
You probably need the other .bin file, commonly called the NVRAM file.
The only A model scope I have is a TDS644A, but try this one from my TDS714L.
You can enable and disable options later via GPIB once it's all booting ok.
-
You probably need the other .bin file, commonly called the NVRAM file.
The only A model scope I have is a TDS644A, but try this one from my TDS714L.
You can enable and disable options later via GPIB once it's all booting ok.
Unless I'm wrong, there is no way a NVRAM's donated from a TDS714L could work on TDS784A or any A serie.
By the way, TDS714L is in fact TDS754D with removed HW and SW options which can be hacked.
-
Well…almost this file has the right size (1Mb), which is the max size of the watchdog chip.
-
714L is all I have, the rest are all C or D. Unfortunately I haven't had an A series TDS700 scope on my bench yet, so you'll have to put the call out.....
Hopefully someone else can rip a couple bin files.
-
Hello fichamba (Jesus), as mentioned somewhere else in this forum, since december 2019 I happen to have repaired, hacked or upgraded nine TDSxxx/C/D plus I did purchase on eBay 6 months ago for interest one TDS510A which runs. From my research, the TDS510A is special beast with logic board compatible with any TDS7x4A but it uses old style acquisition board. The difference with TDS754A, TDS744A or TDS784A is based on its acquisition board similar to C serie acquisition board.
Unless I'm wrong, it could be possible to run your TDS744A with a healthy TDS510A processor board (logic board). What is interesting from synchronicity, check my TDS510A attached pictures where my DS1486 has same time stamp, my DS1650Y different time stamp than yours but looking on year of production, PCB time stamp making, it is the same. The only difference being that it runs with Firmware V1.0e whereas yours V4.1e so one approach would be to reverse your firmware then upgrade later to 4.2e
I kindly recommend that you start a new thread or topic for your problem, after all your problem is not really related to floppy back up but the fact you have no access to any valid NVRAM's content. I intuit more options could be done to save your TDS744A where the key point is how to match your acquisition board.
Albert
-
For TERRA Operative:
Thank you. In Spain we have a sentence: “The one who gives what he/she has, is not obliged to give more”. That’s exactly what you’re doing.
For Tartratron (Albert):
My friend, you are right. I need to open a new thread around this subject. And, BTW…both processor boards looks exactly the same!! With three empty IC places, the rest is identical!. Even the position of the Dallas chips respecting the EPROM! (in “series”, not parallel, as I saw in all boards I normally see). And mine uses also FW 4.1e.
The Batronix programmer will arrive -this time for sure- next Monday. I need “meat” for it!.
Thank you again!
Jesus
-
At last, my TDS784A is alive and kickin' again!. I’ve installed today the new chips from Texas (thanks, David!).
And thanks to all of you who supported my desperation.
Jesus
-
Hi everyone,
First of all let me thank to flyte a lot for this script :-+ I am a happy owner of TDS754D FV:v6.2.1e.
So I used scope formatted floppy with tdsNvramFloppyDumper to back up the calibration constants. All went well, so next I ran the checksum verifier tool to be sure it is correct.
But the result is not what I was expecting. Do any of you have a scope with this FV to confirm if it is just misinterpreted by checksum verifier or if the data are actually corrupted?
Attached is dump of the NVRAM and also checksum verifier result.
Thanks a lot for any idea.
-
Hi guys,
intially I wanted to ask for a help trying to backup the NVSRAM but then my priorities changed as a certain song from The Antwoord came to mind and nose.
Before the baby was on fire I was able to try the procedure for the floppy backup but it was unsuccessful. The issue might now be mute but I will post details anyway, maybe I will be able to fix the scobe, maybe someone else will benefit.
Also for anyone having the same scope, maybe change the elyt caps in your PS. If anyone has schematic diagrams for 640A, please, reach out. I found some schematic diagrams online but they are not corresponding to my power supply.
TDS640A
FW: v3.8.8e
NVSRAM DS1650Y
Tried two different floppy discs, both formated in the scope. When the scope is turned on, it interacts with the floppy drive when the disc in inserted so I assume the drive is fine. I left the switch in the "protected" mode.
a) tdsAcqEEPROMFloppyDumper
- not working (assuming it shouldn't as this is an "A" scope)
b) tdsAcqEEPROMMinimalFloppyDumper
- not working, i.e. no file created on the disc
- I didn't make any mods to the script, was I supposed to?
Change _gtlX24c02Bcopy(0x10A00000,tempBuf,acqEEPROMSize) to _gtlX24c02Bcopy(0x10800000,tempBuf,acqEEPROMSize)?
Thanks!
PS: I created a separate blog post for the HW fail in case you want react to that in particular.
TDS640A Power supply fail and warning https://www.eevblog.com/forum/repair/tds640a-power-supply-fail-and-warning/ (https://www.eevblog.com/forum/repair/tds640a-power-supply-fail-and-warning/)