-
I just upgraded my TDS784C to 5.3e, and it worked fine. Awesome! Big thanks to NathanFulton!
-
Me too have successfully updated my TDS784C to v5.3e.
Time taken 1132 seconds with an NI pcmcia card and 28f016sa flash memory. -
Could someone please post or email me a compiled version of TekTool or TekFWtool for DOS or WIN98.
I am using a NI PCII/IIA GPIB board that works fine.
Doug W6GOT
calmissile@gmail.com -
Hi calmissle
Excuse me, i wouldn't compile software for old PCII/IIA card, because.
I must installed compiler for MS-DOS and searching source file for this card.
But i want check, does work it with Win XP and Win9x and NI 488.2 software?
My software ability is low. -
The one from here doesn't work ?
https://github.com/fenugrec/tekfwtool
I have a wonderful Virtual Box with Borland C++ 3.1 that I can make available to @madao or compile it myself as long as you have the card drivers and library.
-
Could someone please post or email me a compiled version of TekTool or TekFWtool for DOS or WIN98.
I am using a NI PCII/IIA GPIB board that works fine.
I was able to get Unified TekTool running on Win98SE. I needed to put this DLL in the same directory as tektool.exe to get it to work. It comes from the Visual C++ redistributable from around 1998.
-
Would these tools work with a very early TDS540 (no suffix) with probably the oldest firmware around? It still works, and I don't know if the NVRAM has ever been replaced so I want to back it up before it starts dying.
-
Copying out the firmware and NVRAM won't hurt anything, so worth a try.
If you get it out successfully, feel free to post it here and let us know the firmware version so I can upload it to Tekwiki for posterity.
-
Just went to check the firmware, it's v1.10e.
-
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: [Select]C:\tektools>tektool5 -i -b 0x1000000 -l 0x10
base: 01000000
Flash ID1: 0x89898989
identify failed
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: [Select]tektool5 -r fw1_10e.bin -b 0x1000000 -l 0x400000
-
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.
-
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.
-
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 -
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.
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.
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
-
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: [Select]C:\tektools>tektool5 -i -b 0x1000000 -l 0x10
base: 01000000
Flash ID1: 0x89898989
identify failed
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: [Select]tektool5 -r fw1_10e.bin -b 0x1000000 -l 0x400000
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 -
Hello, I have a problem programming the flash 28F010.
If I use the command "tektool -p example.bin -b 0x1000000 -l 0x180000" they are only programmed the flash from 0x1080000 to 0x1100000 ( bank 2 )
But the curious thing:
If I use the command "tektool -p short.bin -b 0x1080000 -l 0x7FFFF" they are programmed the flash from 0x1080000 to 0x1100000 ( bank 2 )
If I use the command "tektool -p short.bin -b 0x1100000 -l 0x7FFFF" they are programmed the flash from 0x1100000 to 0x1180000 ( bank 3 )
The bank 1 not programmed in any case.
The command Read and Erase work perfectly.
This happens with 2 different flash card and 2 different oscilloscope TDS540.
I tried to use 2 different PCI-GPIB National card, but the problem is always the same.
it would be possible to solve this problem ?
Are there any other tests I can try?
Thank you in advance.
Sergio -
Hello Sergio,
Regarding the special case of 28F010 or further the 28F020, there are two models made respectively by Intel and AMD. Who is manufacturer of your 28F010 ?
In case, check attached instructions from madao on length versus flash type.
Albert
-
Hello Albert,
thank you for your interest, I have 2 flash card, one is AMD and one is INTEL and the problem is the same.
I have already read all the instructions of madao.
The lenght 0x180000 for the 28F010 is correct because before to erase I had the backup and the file matches with firmware found in Internet. The are 12 chip x 128K ( 131072 ) = 1.572Kbyte = 0x180000. -
i haven't clue, why it doesn't write data into flash.
Flash program algorithm is same with newer flash on TDS-serie.
Difference of amd and intel shouldn't make problem, because: erase , programming and needing of zero filling is excatly same. Only difference between AMD and Intel is quality. (Intel erasing works much faster and less difference by tries of erase on 12 flash )
Sad, i can't check it again on TDS540 /520 anymore, all is already sold. But i can told, i have check with this puplished unified tektool with all flash. (also one unit with mixed amd /intel flash on one firmware-board )
I can check on TDS544A (not much others than TDS540 with 28F020 ), soon (TM) -
Today the tektool program behaved differently: it programmed bank 1 and 2 correctly and bank 3 all FF, perhaps it depends if I switch the oscilloscope off and on again at each command ..... it's strange.
Just my curiosity, but during the programming of the cells does not make a check? the program does not give any programming errors.
Thank you.
-
this is why: verifty-function is avaible.
-
Verify function gives the error "Firmware corrupt at address 0x100001" that is the start of Bank 3.
I prefer to load the created dump into a binary file reader program to see what is actually loaded in the memories and bank 3 I only see FF. I'm sure the tektool program is having problems on my TDS540. -
Hello Fuma,
Could you make a close view of the 4 flashfile chips from your processor board ?
When you erase all of them with unified tektool command then read all of them again with tektool, are all the values correctly erased ?
Albert -
Hello Albert,
for the first question, the scope it opened, what exactly should I see?
Second question, yes of course, all cells are FF.
Today I discovered another problem, there is a difference between Intel and AMD chip. With Intel banks 1 and 2 are programmed with many cyclic errors, while with AMD they are programmed perfectly. To solve the problem on at least one flash card, tomorrow I'll unsolder the 4 chips of bank 3 and I want to try to program them with the willem eprom programmer but I have to make a adapter and a basic program that divides the binary file of bank 3 into 4 files for each chip ( from 32 to 8 bit bus ).
But I would not unsolder 12 chips for the card with chip Intel ! -
Hello Fuma, yes I meant that you open your scope, look for the 4 flashfile chips then make a close view picture of the 4 chips. If you make a global view of the processor board, we can then tell you where to find the chips then you make a close view picture. Now it seems you have found the issue if there is a mix of AMD and Intel chips, even though on paper they're interchangeable, in practice wether new or older, their response could be different hence your problem.