| Electronics > Repair |
| Unified tektool released ! (Firmware flash tools for old Tektronix TDS series) |
| << < (18/24) > >> |
| DonnieJ:
After getting this TDS684B serial B010740 running again, first order of business was to set about backing up the battery backed up RAM modules. I found this https://github.com/ragges/tektools and specifically https://github.com/ragges/tektools/tree/master/tdsNvramFloppyTool/tdsNvramFloppyDumper doesn’t work. I had to use the Minimal version https://github.com/ragges/tektools/tree/master/tdsNvramFloppyTool/tdsNvramMinimalFloppyDumper which put the NVRAM on the floppy disk. I used the minimal EEPROM dumper to also dump the acquisition board factory calibration. Files below in the B010740 archive. The question is why did the non minimal version not work? I found Tom Verbeure’s work here https://tomverbeure.github.io/2020/07/11/Option-Hacking-the-Tektronix-TDS-420A.html TDS420 is slightly different family, but using the same basic architecture. He documents using Ghidra to look at the ROMs. The ROM in this TDS684B is version 4.3e, but I decided to work on 4.4.1e in Ghidra because that is where this thing will likely end up. The C programs in symext.zip below generate symbol tables to load into Ghidra from the ROM images. Of course, these have VXWorks, and the internal ’shell’ will run any C function that is in the ROM symbol table. The non minimal version is trying to spawn a task from the startup.bat file on the disk: taskSpawn ("nvramdumper",1,0x0,40000,sysExecScript,"fd0:/nvdump.app”) The v4.4.1e (and v4.3e) ROMs don’t have an sysExecScript() function (at least in the symbol table), and so this fails. But after some work in Ghidra setting up decompiling (loading symbols, manually and automatically, manually finding code segments), there is a lot we can do. This https://www.ing.iac.es/~docs/external/vxworks.old/Programmers-Guide-5.4.pdf and https://www.ecb.torontomu.ca/~courses/ee8205/Data-Sheets/Tornado-VxWorks/vxworks/ref/loadLib.html suggest that we can load a.out format 68k code directly into memory. So, let’s build a compiler. See the script compiler-build.sh below in 'C for TDS.zip'. It took a bit of doing because the specific versions are critical... bit rot means that (basically) only these versions support m68k a.out, and also running on x86-64 linux. Then we can try a simple hello world program: jeff:~/work/m68k$ cat t.c extern int open(char * n, int f, int m); extern int write(int fd, char * buf, int n); extern void close(int fd); void do_it() { int fd; fd=open("fd0:/test.txt",0x0202,0x01ff); write(fd, "Hello!", 6); close(fd); } jeff:~/work/m68k$ jeff:~/work/m68k$ ./usr/bin/m68k-aout-gcc -Os -c t.c In theory, we just copy the .o object file over to a floppy, and have the scope load it in startup.bat (files in C for TDS.zip). Then put the floppy in and power on… and see the screen shot. TEST.TXT is created on the disk, along with LOG.TXT that startup.bat created. Here is what they contain: jeff:$ cat /Volumes/NO\ NAME/LOG.TXT value = 4 = 0x4 ioGlobalStdSet(2,outdev) value = 8 = 0x8 printf("Log test %d\n", 42) Log test 42 value = 12 = 0xc printf("running ls\n"); running ls value = 11 = 0xb ls "fd0:/" STARTUP.BAT T.C T.O T.S FSEVEN~1 value = 0 = 0x0 printf("loading module...\n"); loading module... value = 18 = 0x12 fd=open("fd0:/t.o",0,0777) new symbol "fd" added to symbol table. fd = 0x51ede30: value = 7 = 0x7 loadModule(fd, 1) value = 0 = 0x0 close(fd) value = 0 = 0x0 printf(" done.\nRun do_it\n") done. Run do_it value = 17 = 0x11 do_it() value = 0 = 0x0 printf("exiting script\n") exiting script value = 15 = 0xf close(outdev) jeff:$ jeff:$ jeff:$ cat /Volumes/NO\ NAME/TEST.TXT Hello! Yup. We can write code for these scopes in C. |
| DonnieJ:
Traveling the road others have gone... here is a first pass source code and binary of a tektool variant (pretty much a re-write): - that works with AR488 (and maybe Prologix) GPIB adapters. - runs on Unix-like systems - limited for the moment to 28F008SA flash, but easily changed - is fairly fast (about 20min) to write a TDS684B firmware, uses extensive target device side code - but is still a little cranky, mostly timeout issues with AR488. Binaries in here are for MacOS X, but it can easily be compiled for Linux. AR488 may need some of my patches also, I've not pushed them upstream yet. See the readme in the archive for my notes, WIP. I've successfully updated scope B010470 from 4.2e to 4.4.1e... which I think is the last release. Hopefully solves some strange vxWorks behavior I was seeing. Looking for collaborators, even in person (back in Tokyo after the holidays), for testing at least on other TDS hardware. Cheers, and happy holidays. |
| TERRA Operative:
I have the following scopes in my collection I can toy with, as long as they won't get bricked (I want to eventually sell them!), I'm also in Chiba but work in Tokyo, so not too far away. :) I only have the Agilent GPIB - USB adapter, a Contec GPIB - PCMCIA card, and the National Instruments PCII/IIA card in my DOC PC though so I can't do extensive testing with other more modern GPIB adapters. TDS620B TDS644A TDS680B TDS714L TDS754D TDS784C |
| Tantratron:
--- Quote from: madao on February 12, 2020, 05:47:43 pm ---Short story: tekfwtool can't support other than Flash 28F160S5 (which it is using in later TDS 500D/700D series) and other tektool can only 28F016SA (use in C & early D serie). Need for tools for flashing of older instrument is high. --- End quote --- --- Quote from: madao on February 25, 2020, 05:30:53 pm ---But: you can use tekfwtool for flashing unit with 28F160S5. unified tektool take with NI PCI_GPIB at TDS784D: 14 minutes. Of coruse, i use also tekfwtool, if i want program flash at 500/700D. --- End quote --- Hello and Happy New year, As for as I know, the tekfwtool unfortunately does not work on 28F160S5 flashfile memories as stated above. You might want to read my recent experience of bricking one TDS754D and one TDS784D in this post https://www.eevblog.com/forum/repair/tekfwtool-for-tds540c-firmware-upgrade/msg4619995/#msg4619995 when using tekFWtool. Tekfwtool is very fast to flash 28F016A with success but very fast to brick 28F160S5. Unless proven wrong, at your own risk. Albert |
| madao:
--- Quote from: jeroen74 on October 24, 2022, 02:18:31 pm ---So I tried to get it to work today, and surprisingly, after installing all the stuff for the NI GPIB-USB-B adapter the tool works right-away. I can't get it to identify the Flash chips though: --- Code: ---C:\tektools>tektool5 -i -b 0x1000000 -l 0x10 base: 01000000 Flash ID1: 0x89898989 identify failed --- End code --- I managed to download the firmware, but I have no idea if it's actually a proper image :) There's readable text in it that make sense but could as well be an incomplete image. Used this command to get the attached bin file. --- Code: ---tektool5 -r fw1_10e.bin -b 0x1000000 -l 0x400000 --- End code --- --- End quote --- This "tektool5" is not my "unified tektool" unified tektool is capable programming flash of very old TDS540. you can downloading it on first post here (pleas scroll to end of first posting, download " tektool.zip" ) https://www.eevblog.com/forum/repair/unified-tektool-released-!-(firmware-flash-tools-for-old-tds-series)/msg2915458/#msg2915458 |
| Navigation |
| Message Index |
| Next page |
| Previous page |