TDS 744A (& friends) firmware reverse engineering

[fenugrec]

Hi,
so, I have a 744A with some problems; while I'm at it I thought I'd do some reverse engineering. There's a lot of knowledge spread out in forums (here, the Tek forums), some Yahoo groups, and who knows where else.

I'm thinking of adding some info to the w140 wiki but I'm not sure where it would fit in on there.

My main interest is the internal service console port (see https://forum.tek.com/viewtopic.php?f=568&t=137307 ).
From that console port, the "lkup" command outputs a list of over 5000 (!) symbols, many of which are callable functions :

http://pastebin.com/yEnTKHwG

look at, for example, the familiar "libManagerWordAtPut" entries and related entries.
These are also intriguing:

Code: [Select]

_enableBackdoor 0x011c70d6  text    18641110
_checkBackDoor  0x011c7166  text    18641254

I could dump the firmware through the console port but that would be extremely slow (9600bps serial link; ASCII hex dump so 3 chars per byte; firmware image at least 2.5MB ). Does anyone have a firmware dump for one of these TDS scopes ?

[dxl]

Here you go:

https://stackframe.org/tekfwtool/

https://stackframe.org/tektool.shtml

[snoopy]

Here you go:

https://stackframe.org/tekfwtool/

https://stackframe.org/tektool.shtml

I can't seem to download anything from that site. Also what USB to GPIB interface do you recommend ?

cheers

[Jwalling]

The 784D and 784C firmware is here: http://www.ko4bb.com/getsimple/index.php?id=manuals

Put TDS784D or TDS784C in the search box.

[fenugrec]

@dxl , @Jwalling, thanks ! for some reason I didn't even think of checking KO4BB. Interesting that there are no 744A dumps though.

[Jay_Diddy_B]

Hi,

I suspect the 744A, 754A and 784A all use the same firmware ;-)

Jay_Diddy_B

[dxl]

@dxl , @Jwalling, thanks ! for some reason I didn't even think of checking KO4BB. Interesting that there are no 744A dumps though.

Well, the reason is that i uploaded the dumps when i wrote the tekfwtool. And i simply didn't had a TDS744

[dxl]

Hi,

I suspect the 744A, 754A and 784A all use the same firmware ;-)

Jay_Diddy_B

Not sure. I tried 'upgrading' my TDS784D at that time to a newer version i fetched from another TDS784D. That didn't work. It booted, but made all kinds of strange effects. I don't remember the details, but either the calibration data format changes between versions, or only specific firmware version run on a scope.

[andy2000]

I upgraded my 784D successfully to version 6.6e without trouble.  I've heard that version 7.x requires a different processor board.  Your experience might confirm that.

Be aware that upgrading a 744A does require recalibration because the new firmware doesn't recognize the old calibration.

[dxl]

I upgraded my 784D successfully to version 6.6e without trouble.  I've heard that version 7.x requires a different processor board.  Your experience might confirm that.

Be aware that upgrading a 744A does require recalibration because the new firmware doesn't recognize the old calibration.

I guess you're right - i think i tried to upgrade from 6.6e to 7.2e at that time.

[james_s]

I'd be interested in seeing any information you manage to gain from this. I'm always curious to know more about how things work and I have a TDS784C myself. Fantastic piece of gear, I just wish there was more information out there on it.

[fenugrec]

I started looking at some of those 784C/784D dumps, but it would really help if someone could hook up to the service port and run "lkup" - that would print out the symbol list which will be a huge help to analyze the firmware.

My TDS744A has firmware 1.1e and it's just too different to these 7xxC / 7xxD models. Don't those later ones have some java garbage in them too ?

****
Some other commands for the service console :

Code: [Select]

ringBell ( ding !! I love how these have a nice bell sound instead of the simpler piezo buzzer they could've chosen instead)

Code: [Select]

HWADumpOptValues
HWADumpCpuValues
HWADumpSysValues


[james_s]

Is this something I can do over the GPIB interface? I'd be happy to give it a try over the weekend. I have not made a serial console cable for it yet but that's another thing on my list.

[fenugrec]

Is this something I can do over the GPIB interface?

I don't think so, unfortunately.

I'm slowly dumping small chunks of my firmware through the service port ( ~ 150B/s ! slo-o-ow). I think I might be able to change its speed from 9600bps to something more usable... maybe.

[dxl]

Is this something I can do over the GPIB interface?

I don't think so, unfortunately.

I'm slowly dumping small chunks of my firmware through the service port ( ~ 150B/s ! slo-o-ow). I think I might be able to change its speed from 9600bps to something more usable... maybe.

There is an option to do it via GPIB. If you set the Calibration switch to 'unprotected' and power on the scope it will appear dead (nothing on the screen, no sound, etc). But it isn't dead. It spawns a minimalistic bootloader, which listen on GPIB address 29 (IIRC), and that will accept commands via GPIB. The format is binary, so you cannot talk with the usual GPIB commands to it.

This is where my tekfwtool comes into the picture - you can start it on your PC, and it will download a minimal binary to the scope which get's executed and takes care about reading/writing memory.

As mentioned before, tekfwtool is here:

https://stackframe.org/tekfwtool/

It's been a while since i used it the last time, but you propably need:

https://stackframe.org/tekfwtool/tekfwtool.exe and https://stackframe.org/tekfwtool/target.bin

[andy2000]

Is this something I can do over the GPIB interface?

I don't think so, unfortunately.

I'm slowly dumping small chunks of my firmware through the service port ( ~ 150B/s ! slo-o-ow). I think I might be able to change its speed from 9600bps to something more usable... maybe.

There is an option to do it via GPIB. If you set the Calibration switch to 'unprotected' and power on the scope it will appear dead (nothing on the screen, no sound, etc). But it isn't dead. It spawns a minimalistic bootloader, which listen on GPIB address 29 (IIRC), and that will accept commands via GPIB. The format is binary, so you cannot talk with the usual GPIB commands to it.

This is where my tekfwtool comes into the picture - you can start it on your PC, and it will download a minimal binary to the scope which get's executed and takes care about reading/writing memory.

As mentioned before, tekfwtool is here:

https://stackframe.org/tekfwtool/

It's been a while since i used it the last time, but you propably need:

https://stackframe.org/tekfwtool/tekfwtool.exe and https://stackframe.org/tekfwtool/target.bin

I just get this when I try to download those files:

Forbidden

You don't have permission to access /tekfwtool/tekfwtool.exe on this server.
Apache/2.4.18 (Ubuntu) Server at stackframe.org Port 443

[dxl]

I just get this when I try to download those files:

Forbidden

You don't have permission to access /tekfwtool/tekfwtool.exe on this server.
Apache/2.4.18 (Ubuntu) Server at stackframe.org Port 443

Whoops, my fault. Should be fixed now.

[fenugrec]

There is an option to do it via GPIB. If you set the Calibration switch to 'unprotected'

Oh yes, I'm aware of that but not equipped with any kind of GPIB hardware (yet) so I'm trying to do everything from the service port. Which is theoretically possible since it gives access to everything, essentially.

Interestingly, when booting the scope in Unprotected mode, it seems the service port doesn't run a command interpreter anymore, but is only used as a debug output. I wasn't able to enter any commands while Unprotected.

[snoopy]

I just get this when I try to download those files:

Forbidden

You don't have permission to access /tekfwtool/tekfwtool.exe on this server.
Apache/2.4.18 (Ubuntu) Server at stackframe.org Port 443

Whoops, my fault. Should be fixed now.

Avast is flagging a DRep virus when I try and download the exe. Is this a false positive ?

cheers

[1Ghz]

Avast is flagging a DRep virus when I try and download the exe. Is this a false positive ?

Seems to be a false positive. See link below.

https://forum.avast.com/index.php?topic=163221.msg1164286#msg1164286

[snoopy]

Avast is flagging a DRep virus when I try and download the exe. Is this a false positive ?

Seems to be a false positive. See link below.

https://forum.avast.com/index.php?topic=163221.msg1164286#msg1164286

Does anyone know how I can bypass this so I can download the file ?

cheers

[Jwalling]

I just get this when I try to download those files:

Forbidden

You don't have permission to access /tekfwtool/tekfwtool.exe on this server.
Apache/2.4.18 (Ubuntu) Server at stackframe.org Port 443

Whoops, my fault. Should be fixed now.

Avast is flagging a DRep virus when I try and download the exe. Is this a false positive ?

cheers

Norton reports this:
https://us.norton.com/security_response/writeup.jsp?docid=2010-051308-1854-99

Virustotal sees nothing wrong with it. 0/61
https://www.virustotal.com/en/file/40b810b6dd88b8a65b9b5f5138c7669fc0f81222ebc58e463de0d0fdd19f2f21/analysis/1490533278/
You should be able to temporarily disable your virus protection.

[snoopy]

I just get this when I try to download those files:

Forbidden

You don't have permission to access /tekfwtool/tekfwtool.exe on this server.
Apache/2.4.18 (Ubuntu) Server at stackframe.org Port 443

Whoops, my fault. Should be fixed now.

Avast is flagging a DRep virus when I try and download the exe. Is this a false positive ?

cheers

Norton reports this:
https://us.norton.com/security_response/writeup.jsp?docid=2010-051308-1854-99

Virustotal sees nothing wrong with it. 0/61
https://www.virustotal.com/en/file/40b810b6dd88b8a65b9b5f5138c7669fc0f81222ebc58e463de0d0fdd19f2f21/analysis/1490533278/
You should be able to temporarily disable your virus protection.

Yes I temporarily disabled avast and downloaded it and did a scan and avast wanted to take a copy and analyse it and later get back to me. By that time I went off to bed.

cheers

[fenugrec]

For anyone having problems downloading the .exe, I don't think it would be very hard to compile from source.

[Jwalling]

I'd be happy to get the firmware from a TDS784A (V4.1e) but the Tekfwtool doesn't seem to work for me.
I get this:

Code: [Select]

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\TekFWtool>tekfwtool -r test.bin -b 0x01000000 -l 0x400000
Unable to open device
ibsta = 0x8000 iberr = 0

E:\TekFWtool>
I'm using a Prologix USB to GPIB converter which looks like a serial port to the system. Maybe that's the problem? Does it require an NI GPIB adapter?

[dxl]

I'd be happy to get the firmware from a TDS784A (V4.1e) but the Tekfwtool doesn't seem to work for me.
I get this:

Code: [Select]

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\TekFWtool>tekfwtool -r test.bin -b 0x01000000 -l 0x400000
Unable to open device
ibsta = 0x8000 iberr = 0

E:\TekFWtool>
I'm using a Prologix USB to GPIB converter which looks like a serial port to the system. Maybe that's the problem? Does it require an NI GPIB adapter?

Yes, it only supports NI-VISA. I didn't had any other GPIB adapter except a GPIB-USB-HS at that time.

[james_s]

Somebody needs to come up with a driver that emulates the NI hardware and allows one of the newer USB based interfaces to work. I built my GPIB adapter out of an Arduino nano clone using code I found online. Total cost less than $10 and most of that was the GPIB cable I cut in half to make the adapter. Works great, but shows up as a serial port.

[alm]

NI-VISA supports their current GPIB-USB-HS and GPIB-USB-HS+ adapters. Not just their old stuff. That is partly why there adapters cost $500 instead of $100 (that, and actually conforming to the IEEE 488 specs, so you can drive 15 devices with 20 meters of cable). Generally it is up to the GPIB adapter manufacturer to provide drivers (like VISA and gpib32). For example, Agilent/Keysight provide their own VISA implementation for their own hardware. I am not aware of any VISA implementation that supports for the cheap devices that implement an USB serial port. When Prologix talk about Labview support they usually mean that you can adapt your Labview program to interface with their hardware, not use it as drop-in replacement for a real GPIB adapter.

It may be that one of the knock-off Agilent adapters (have they been updated to the Keysight branding yet?) will work with the Agilent/Keysight software, although I do not condone buying knock-off devices that rely on the manufacturer they copied to provide software. Used NI/Agilent devices are sometimes available on eBay for under $200. Be sure to check which devices are still supported by their current software releases. I would not buy a used Agilent adapter from China given the volume of fake Agilent adapters. You could also get one of the cheap NI PCI or maybe even ISA cards if it is just for dumping the scope (if you have a computer and an OS version that supports them).

[fenugrec]

Somebody needs to come up with a driver that emulates the NI hardware

Haha "somebody" should, indeed - I think the NI API is sufficiently documented to make this possible, but on the other side "someone" needs to abstract out the differences between a variety of different GPIB hardware, else design a new one. An interesting project; I'd be willing to contribute but I will not be providing any initiative for this -  I have too many active projects already sharing the "open source spare time".

Note, there has been some initial work done vaguely in that direction, loosely affiliated with sigrok
http://sigrok.org/wiki/Gpibgrok
but as usual for this type of project, a few people will read a bunch of datasheets, draw up a BOM, rough schematics and maybe a PCB, and that's about where it ends. I know this pattern, I've done the same thing a few times.


Back to firmware --
@Jwalling, do you have the internal service port hooked up too ?

[Jwalling]

Somebody needs to come up with a driver that emulates the NI hardware

Haha "somebody" should, indeed - I think the NI API is sufficiently documented to make this possible, but on the other side "someone" needs to abstract out the differences between a variety of different GPIB hardware, else design a new one. An interesting project; I'd be willing to contribute but I will not be providing any initiative for this -  I have too many active projects already sharing the "open source spare time".

Note, there has been some initial work done vaguely in that direction, loosely affiliated with sigrok
http://sigrok.org/wiki/Gpibgrok
but as usual for this type of project, a few people will read a bunch of datasheets, draw up a BOM, rough schematics and maybe a PCB, and that's about where it ends. I know this pattern, I've done the same thing a few times.


Back to firmware --
@Jwalling, do you have the internal service port hooked up too ?

I did make a console port adapter using the info here and a spare option 13 adapter:
https://forum.tek.com/viewtopic.php?f=568&t=137307&sid=4ff0c574ac18b981c98f0a3077b1d867

(Note that that pinout left power and ground unconnected to the option 13 board for some reason...)

Is that what you mean? Is there a way to dump the firmware through the console port?

[james_s]

Note, there has been some initial work done vaguely in that direction, loosely affiliated with sigrok
http://sigrok.org/wiki/Gpibgrok
but as usual for this type of project, a few people will read a bunch of datasheets, draw up a BOM, rough schematics and maybe a PCB, and that's about where it ends. I know this pattern, I've done the same thing a few times.

Well we already have all that, the Arduino based open source GPIB interface works just fine from a hardware standpoint. What is needed is a software driver to interface with it. I'm not much of a programmer myself, I'm much better with hardware.

[fenugrec]

Is that what you mean? Is there a way to dump the firmware through the console port?

Mostly -- yes you can dump the firmware through the console port, but it's *painfully* slow, so my goal is to find a matching set of

a) firmware dump (GPIB + tektool )
b) corresponding "symbol table", which can only (to my knowledge) be obtained from the service port with the command "lkup"

Different firmware versions will have different symbol tables so they both really need to be from the same FW version.

The symbol table is essentially a list of names (functions and variables) + their addresses, which is a tremendous help for reverse engineering.

[snoopy]

Would this GPIB USB interface be suitable ?

http://www.ebay.com/itm/UG01-USB-to-GPIB-Controller-Made-in-USA-/282245791693?

[james_s]

It's a lot cheaper to build one, this is what I have http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html

I used an arduino nano clone that cost $2.50 and got a cable for $7.50 that I cut the end off and soldered the wires to the Arduino board. Heatshrink over that and it's done.

[smartboy123]

Is this something I can do over the GPIB interface?

I don't think so, unfortunately.

I'm slowly dumping small chunks of my firmware through the service port ( ~ 150B/s ! slo-o-ow). I think I might be able to change its speed from 9600bps to something more usable... maybe.

There is an option to do it via GPIB. If you set the Calibration switch to 'unprotected' and power on the scope it will appear dead (nothing on the screen, no sound, etc). But it isn't dead. It spawns a minimalistic bootloader, which listen on GPIB address 29 (IIRC), and that will accept commands via GPIB. The format is binary, so you cannot talk with the usual GPIB commands to it.

This is where my tekfwtool comes into the picture - you can start it on your PC, and it will download a minimal binary to the scope which get's executed and takes care about reading/writing memory.

As mentioned before, tekfwtool is here:

https://stackframe.org/tekfwtool/

It's been a while since i used it the last time, but you propably need:

https://stackframe.org/tekfwtool/tekfwtool.exe and https://stackframe.org/tekfwtool/target.bin

I have a TDS784D with firmware version v7.2e, and I'd like to update it to v7.4e. Using Agilent 82357B USB-GPIB adaptor, I execute followed command using your tools:
tektool -e -b 0x01000000 -l 0x10
tektool -w firmware.bin -b 0x01000000 -l 0x400000
The flash erase and program process is smooth, however, after I protected the firmware and restart my device, it doesn't work any more.

Then I roll back to my original firmware(before I program the firmware, I backup the flash to my PC using your tools), unfortunately it still doesn't work.

Before I damage my device by update firmware, I try the NVRAM read/write using your tools, it work very well, so I decide to program the Flash, then a disaster!

Now I totally no idea about how to recover my device, could you give some suggestion?


 

[smartboy123]

I read the flash content, it all 0xFF, 0xFF, so that means I erase the flash correct, however, program fail, maybe my flash chip is not supported by tekfwtool.

Is there any other firmware update method, for example through floppy disk?

[smartboy123]

In tekfwtool web page, it said "only 28F016SA type flash currently supported, takes about half an hour with my GPIB-USB-A cable".
I checked my flash chip, it's TE28F160S570, can tekfwtool support this flash chip?
I found some information in target.c as followed:
struct flash_descriptor flash_types[] = {
    /* Intel TE28F160S5 */
    {   .manufacturer = 0xb0,
   .device = 0xd0,
   .size = 0x200000,
   .blocksize = 0x200,
   .erase_chip = flash_erase_intel_s5,
   .program_single = flash_program_single_cmd40,
    },{
   /* Intel E28F016SA */
   .manufacturer = 0x89,
   .device = 0xa0,
   .size = 0x200000,
   .blocksize = 0x200,
   .erase_chip = flash_erase_intel_sa,
   .program_single = flash_program_single_cmd40,
   .program_page = flash_program_page_intel_sa,
    }
};

I wonder whether tekfwtool support intel TE28F160 or not?

[capt bullshot]

I have a TDS784D with firmware version v7.2e, and I'd like to update it to v7.4e. Using Agilent 82357B USB-GPIB adaptor, I execute followed command using your tools:
tektool -e -b 0x01000000 -l 0x10
tektool -w firmware.bin -b 0x01000000 -l 0x400000
The flash erase and program process is smooth, however, after I protected the firmware and restart my device, it doesn't work any more.

Then I roll back to my original firmware(before I program the firmware, I backup the flash to my PC using your tools), unfortunately it still doesn't work.

Before I damage my device by update firmware, I try the NVRAM read/write using your tools, it work very well, so I decide to program the Flash, then a disaster!

Now I totally no idea about how to recover my device, could you give some suggestion?

There's some mistake in the documentation of tektool, try:
tektool -p firmware.bin -b 0x01000000 -l 0x400000

-w writes to memory (like the NVRAM)
-p programs the flash memory (writing alone doesn't work)

[smartboy123]

 
Using "-p" option, my dead device was updated to newest firmware v7.4e now.
Thank you very much.

[dxl]

Whoops, looks like i have to update the documentation. But glad to hear that it works for you now and the scope isn't bricked.

[kc7gr-15]

Time to give this topic a nudge. I've got a TDS784D, and have successfully used the tekfwtool executable to read and archive both my NVRAM settings and my current firmware version (6.something). My thanks for providing such a useful widget!

I'd like to put in the last/latest firmware (7.4e), but I saw a post in this thread to the effect that 7.4e may need a different CPU board. Did anyone ever find out anything more about this?

Also -- The .bin files I downloaded, from the ko4bb.com site, for 7.4e include a bootrom.bin file. In contrast, the other firmware file I found for 7.4e is just a single 4MB file. What address position would one need to use, in the tool, to update the bootrom? (Assuming it even needs it).

Thoughts welcome... Thanks much!

[Jwalling]

I'd like to put in the last/latest firmware (7.4e), but I saw a post in this thread to the effect that 7.4e may need a different CPU board. Did anyone ever find out anything more about this?

I would be careful doing this unless there's a way to roll it back. I think I remember reading somewhere that this will require a full calibration of the scope.

[kc7gr-15]

Thank you. I did indeed make sure I had a fallback ready, in the form of backup images of both flash and NVRAM, before I started experimenting.

Sadly, it seems to have done me little good. My experiments last night have left me with a bricked scope (thankfully, though, the unprotected mode bootloader still works, so I can continue to try reloading/restoration). However, after doing some before-and-after comparisons of the firmware source file and what's getting programmed into the scope's flash (using tekfwtool's -r function), I find differences where there should not be any.

This tells me that, for some reason, the firmware is getting corrupted as it gets written into flash. This also means any restoration attempt will likely fail until I can locate and correct the problem.

One possibility has occurred to me, and I've left dxl a PM asking for his thoughts on it. My computer/GPIB environment is Windows XP with the NI PCI-GPIB board and drivers. I've been running tekfwtool in a "command window."

No matter what the response from dxl, I'm going to try a pure MS-DOS environment as my next step. I really have nothing to lose at this point. Failing that, I'll try an ISA-based GPIB card. My thinking is the current interface may actually be operating too fast to reliably write to the scope, which could be causing the corruption (I've seen similar things happen with serial port overruns).

I'm not giving up on this, even if I end up having to physically remove and program the flash chips manually or replace the entire CPU board. What I learn, and share with others, will be of value no matter what happens.

Thanks much.

[Jwalling]

Thank you. I did indeed make sure I had a fallback ready, in the form of backup images of both flash and NVRAM, before I started experimenting.

Sadly, it seems to have done me little good. My experiments last night have left me with a bricked scope (thankfully, though, the unprotected mode bootloader still works, so I can continue to try reloading/restoration). However, after doing some before-and-after comparisons of the firmware source file and what's getting programmed into the scope's flash (using tekfwtool's -r function), I find differences where there should not be any.

This tells me that, for some reason, the firmware is getting corrupted as it gets written into flash. This also means any restoration attempt will likely fail until I can locate and correct the problem.

One possibility has occurred to me, and I've left dxl a PM asking for his thoughts on it. My computer/GPIB environment is Windows XP with the NI PCI-GPIB board and drivers. I've been running tekfwtool in a "command window."

No matter what the response from dxl, I'm going to try a pure MS-DOS environment as my next step. I really have nothing to lose at this point. Failing that, I'll try an ISA-based GPIB card. My thinking is the current interface may actually be operating too fast to reliably write to the scope, which could be causing the corruption (I've seen similar things happen with serial port overruns).

I'm not giving up on this, even if I end up having to physically remove and program the flash chips manually or replace the entire CPU board. What I learn, and share with others, will be of value no matter what happens.

Thanks much.

Ouch, that hurts. After you have a look at the flash chips, that might be a difficult task. You'll need a special adapter for your programmer, can't remember the package name but the pins are very tiny. I have transplanted flash chips from a 700D series into a 684C CPU board, but it wasn't easy. (At least for me.)

Good luck!

[kc7gr-15]

Well, we're not to the point of chip-swapping just yet. Even if it comes to that, I'm set up for it (Metcal solder/desolder system, and I just got the micro-fine handpiece and tips for it).

As for the programmer: Also, not a problem. The package type is TSOP (Thin Small-Outline Package), and I have several adapters for the various pin counts. Data I/O did a nice job with the Unisite/Pinsite adapter combo.

No, I still want to try the all-MSDOS system approach. I'm really beginning to think I ran afoul of trying to run the firmware tool under an XP command window, especially since other posts I've read have indicated others in my situation were able to successfully recover their scope from a bricked state (and, as far as I know, they were using MS-DOS).

I'll post further updates as I get them. Keep the peace(es).

[kc7gr-15]

OK, I need to set things aside and move on (for the moment... I'm not giving up, just taking a break).

I got the tekfwtool -p option to work exactly ONCE. Since the -e option didn't seem to be working (I'd get some bizarre error), I got the bright idea of creating an appropriate-length file filled with hex 00 (maybe I should have used FF) and trying to program it in. It worked... My flash is now a blank slate where the firmware normally is (address 0x1000000, for 4194304 bytes after that), but now the scope won't take any further write attempts using the tool. It acts like it does... The tool runs, and gives the expected screen display, but nothing happens to the flash. The scope remains bricked.

One thing I did discover. The copy of the service manual I have lists the CPU board as part number 679-4172-00. However, the more common CPU board seems to be 679-4349-00 (judging, at least, from what I've seen on Ebay). Perhaps this was a late changeout by Tek...?

Anyway, I've updated the tool's creator (dxl) via PM, so I'll give it a few days and see what he has to say. I'm also going to go see if I have a desolder tip for 4o-pin TSOP's...

Keep the peace(es).

[kc7gr-15]

Fellow Tek Tweakers,

The adventure is over! After ending up with a 'bricked' TDS784D, I was able to recover it to full operation this evening with the aid of some very smart people over on the Tektronix forum. For the entire story, see this thread: https://forum.tek.com/viewtopic.php?f=568&t=140017

Just in case that link ceases to work, I'll repeat much of what I mentioned here.

First, the programming tool. I'm sorry to say I had only limited success with tekfwtool. I was able to read my 'scope's guts with it, and make backups of both NVRAM and firmware, but trying to write back to it (at least with a PCI-based GPIB card) resulted in corrupted firmware and a bricked unit.

What did finally work was using the original tool (tektool_0.exe) from the file package mentioned in that thread referenced above (it should be downloadable by anyone... If not, I have it on my public FTP archive), in combination with an ISA-based GPIB card (specifically, a AT-GPIB from NI). In retrospect, I have to wonder if a PCI-based setup simply runs too fast in some way or other...?

Some notes on the O-scopes themselves: It seems there are differences in the version of CPU and Acquisition board used on the TDS7xxD series, and NOT all firmware loads are compatible with them. I would strongly recommend checking both the serial number AND doing an actual visual check of the part number labels on the boards before you even think of messing with firmware updates.

Specifically: Serial numbers LOWER THAN B04xxxx may have CPU board part number 679-4172-00. This board is NOT compatible with anything later than firmware version 6.6e, nor is the acquisition board which it pairs with. It also uses Intel 28F016 FLASH chips.

Serial numbers of B04xxxx and higher will likely have CPU P/N 679-4349-00. This board, and its matching acquisition board, need firmware version 7.4e to work (other versions in the 7.x series may work as well -- That would be a question for Tek support). It uses Intel 28F160 chips, and may require a different version of tektool (or, perhaps, tekfwtool) to support.

There's a couple of other things I learned during the recovery process. First, that seven-segment display on the CPU board can convey quite a bit of information. Under normal conditions, with a 'scope which is booted and running normally, the top and bottom segments (a and d, if I remember correctly) should be alternately flashing at about a 2Hz rate.

When the 'scope is in 'Unprotected' mode, the display will count up to numeric 8 and remain there. Parts of it will likely flicker if you start reading or writing processes with tektool.

When you have a 'scope with a mismatched CPU and Acquisition board (Example: 679-4349-00 CPU paired with a pre-B04xxxx acquisition board), you'll get as far as the 'Digital Phosphor Oscilloscope' splash screen, after which it will blank and the alternating flash on the seven-segment display will freeze with one or the other segments dimly lit. This is the TDS equivalent of a Microsoft 'Blue Screen of Death.'

On using tektool or tekfwtool itself: If the tekfwtool -e or tektool -e commands do not show you a series of strings of zeroes when you execute them, your flash is NOT being erased and the program will likely spit back an error code after about a minute. This is a sign that your GPIB setup may not be optimal, and you should try a different arrangement (in my case, I have every reason to believe the switch from a PCI to an ISA-based card is what did the trick).

Keep experimenting, and post your own results (especially if they differ from mine). Hopefully, between this thread and the one on the Tek forums, anyone else who's struggling with a TDS7xx series will be able to come out of it a winner. 

Now, if you'll excuse me, I just have to put the outer case back on my unit and return it to its spot on the bench. My thanks to all who replied, here and on the Tek forum.

73 de KC7GR

[Jwalling]

When you have a 'scope with a mismatched CPU and Acquisition board (Example: 679-4349-00 CPU paired with a pre-B04xxxx acquisition board), you'll get as far as the 'Digital Phosphor Oscilloscope' splash screen, after which it will blank and the alternating flash on the seven-segment display will freeze with one or the other segments dimly lit. This is the TDS equivalent of a Microsoft 'Blue Screen of Death.'

That's not too surprising. I believe that the ACQ boards on prefix B040XXX and higher combined the 4 A/D converters into 1 chip where previously there were 4.

Anyway, good job! You probably have a few more grey hairs now...

[kc7gr-15]

Thanks, Jay. Even if I did gain more gray, it was worth it, especially if I end up helping someone else correct a similar goof.

Next step: Attenuator relay changeout.

Keep the peace(es).

[Scratch.HTF]

How about emulating the oscilloscope with MAME?
This is one way of finding out how to unlock software options e.g. FFT etc.

[charlyd]

Yes that is correct i have a TDS784D and a TDS754D here both have CPU board seems to be 679-4349-00 .
The ACQ board is  679-4771-01.

[smartboy123]

Whoops, looks like i have to update the documentation. But glad to hear that it works for you now and the scope isn't bricked.

Your document is still with typo error, I check just now   

[charlyd]

typo error for what?

[fenugrec]

Nice to see some action here, even if it's not quite in the direction I was hoping. Does anyone have the combination of the following :

- TDS7xx scope
- dumped firmware (either dumped themselves, or available online like ko4bb's archive)
- internal service port hooked up

Each of these is easy, but I have yet to find a *matching* combination of the correct fw version dump, plus someone with the service port hookup.

[EDIT]
I am now GPIB-enabled, and also I have just found dxl's github repo : )
https://github.com/sschnelle/tekfwtool

[fenugrec]

Finally, I have dumped my TDS744A v1.1e firmware and NVRAM areas.
For the moment they're in "recent uploads" on KO4BB
http://www.ko4bb.com/getsimple/index.php?id=manuals&dir=07_Recent_Uploads

I had to "backport" dxl's tekfwtool to compile and run on DOS, since the computer with the GPIB-AT card runs freeDOS !
More details on that patch @ https://github.com/sschnelle/tekfwtool/pull/1

[fenugrec]

I've started analysis work on my 1.1e ROM . Lots of interesting stuff ! Having the symbol table is a tremendous help.

Here's a few interesting things I've found so far, sifting through the symbols and disassembly:

- "_Unpack_text" .  A lot of text is packed (compressed) into a raw array (aptly named _Packed_text ), and accessed through a table of records ("_RecIndex"). On my ROM there are 648 strings, for a total of ~58kB of packed data ! I guess pretty much all the UI stuff is in there; the other plaintext strings in the ROM seem to be mostly debugging / logging.

- On my ROM, a certain number of functions (like _RunAcqDiagCh1) are not implemented and jump to the generic "_stubme" function that just logs an error.

- the rs232 comms function would probably allow to set a custom, higher baudrate for the service console. This would make dumping the ROM over the console port a viable option.

- the ability to do basically everything from the service console means that there's no real technical obstacle to reflashing / modifying options from the console port, instead of requiring a GPIB connection.

I'm not sure why there's apparently so little hacking done on the firmware for these. The CPU is a well known 68k architecture, the ROMs are fairly easy to dump and/or available online, and for goodness sake they include an exhaustive symbol table that maps almost every important function and global variable !!

Plus, if I'm not mistaken there's plenty of ROM space left. This opens the door to all kinds tweaks and hacks.

[james_s]

It would be awesome if someone managed to add SPI/I2C/Serial/etc protocol decoding. That's about the only thing I can think of lacking in these scopes compared to more modern instruments.

[fenugrec]

I imagine the structure and implementation of these scope's firmware will be very, very similar between versions and models. All the info I present is based on my own TDS744A with 1.1e firmware.

************** ROM header
Yay, the main ROM has a header with meaningful metadata !

It looks like this :

Code: [Select]

// the sizeof()  for this is 0x2C (determined by checksum code in kernel ROM)
struct flashhdr_short {
u8 jmp_trampoline[8]; // "nop", then "jmp _romInit"
u32 cksum_body_start; //ptr to beginning of body area to sum
u32 idata_start; // initial vals for _sdata in RAM
u32 sdata; //addr of _sdata in RAM
u32 bss_start; //also end of _sdata area
u32 cksum_body; //32-bit checkum of body area
u8 unknown[6];
u8 padding[8]; //always 0xFF bytes ?
u16 cksum_hdr; //checksum of this header
};

************* Boot process (main ROM startup)
Part of the boot process goes like this :

• the kernel ROM jumps to the main ROM jmp "trampoline" (at 0x100 0000). This jumps to
• _romInit : does some basic ROM / RAM checks, including calling _InitDataSpace. Then passes control to _usrInit.
• _InitDataSpace : short function that initializes the "_sdata" section in RAM with data from the ROM's idata section; also clears the bss section in RAM.
• _usrInit : preps the interrupt and exception vectors, then calls _kernelInit . Note ! starting here, "kernel" refers to the VxWorks kernel and not the one that ran on initial power up. This function initializes Vx with a new task :
• _usrRoot ; things get interesting.  It calls some interesting functions like _led_walk, _bumpLed, _symTblAdd (more on this later) , _printLogo ( !) and others. Then things branch out a lot due to the use of _taskSpawn .

************* symbol table
It took me a while to figure all this out, but here's some information that will
make the process easier when analyzing a new ROM.

ROM format : as we know the main ROM is mapped at 0x0100 0000 in the address
space. This must be kept in mind when looking at the raw data.  For instance,
 to be able to parse the ROM's built-in symbol table. This table
is the golden key : it associates a readable name to many, many functions and variables.
Each symbol item looks like this :

Code: [Select]

struct sym_item {
u32 unknown_0; //always 0 ?
u32 pName; //point to string
u32 pItem; //point to actual item (function or variable)
u8 type; //not 100% sure. 5 = code,  7 = idata, 9 = bss data ?
u8 unknown_1; //always 0 ?
};
Here's an example :

Code: [Select]

00 00 00 00   01 27 3E 6D    01 1E 0D 9E   05   00pName = 0x0127 3E6D , if we look inside the ROM at 0x273E6D, there's a string "_validateBootRomHeader"
pItem = 0x011E 0D9E, this is the entry point of that function.
type = 5, by now I'm pretty sure 5 means code, 7 and 9 are variables in RAM.


This symbol table is huge (5300 entries on my ROM) and quite conspicuous;
moreover its location at the end of the .idata section makes it pretty easy to find.
Allow me to save a thousand words :

Code: [Select]

                                            Location in address space
                                            (= ROM file offset + 0x0100 000)

    +-------------------------------------+
    | ROM image header                    | 0x0100 0000
    +-------------------------------------+
    | copyright strings                   | 0x0100 002C
    |                                     |
    |                                     |
    +-------------------------------------+
    | .text  |                            | 0x0100 01AA : _startChecksumming
    |        |  some code                 |
    |        |  "VROM" chunk              |
    |        |                            |
    |        |  more code                 |
    |        |                            |
    |        |                            |
    |        |  strings for each symbol   |
    |        |  (not copied to RAM)       |
    |        |                            |
    |        |                            |
    +-------------------------------------+
    | .idata | generic data               |  0x12750AA
    |        |                            |
    |        |                            |
    |        +----------------------------+
    |        | symlist[num_of_entries]    |  0x0129 92E8
    |        |                            |
    |        +----------------------------+
    |        | sym_num_of_entries         |  0x012A B474
    +-------------------------------------+
    | empty (0xFF)                        |  0x012A B47C
    |                                     |
    |                                     |
    |                                     |
    +-------------------------------------+  0x013F FFFF

*************
I think that's enough writing for today.
I'd love to hear from anyone else looking at these ROMs !

[ZL1CVD]

could you please tell me you software setup for doing this with Agilent 82357B. I have same Agilent USB GPIB, Windows 7 64-bit, TDS-744A. I have NVSRAM & RTC to change out and need to back up everything before I do. Just not sure how to go about reading firmware and NVSRAM so any help would be greatly appreciated. 

[KE5FX]

Looks like the tekfwtool Github page gibt's nicht mehr.    Is there an updated link somewhere?

[DC1MC]

Looks like the tekfwtool Github page gibt's nicht mehr.    Is there an updated link somewhere?

Außerhalb von Github gibt's Leben auch:
https://stackframe.org/tekfwtool/

[KE5FX]

Looks like the tekfwtool Github page gibt's nicht mehr.    Is there an updated link somewhere?

Außerhalb von Github gibt's Leben auch:
https://stackframe.org/tekfwtool/

True, but that's just the original link -- I was under the impression that some updates/fixes had been made.

[DC1MC]

Looks like the tekfwtool Github page gibt's nicht mehr.    Is there an updated link somewhere?

Außerhalb von Github gibt's Leben auch:
https://stackframe.org/tekfwtool/

True, but that's just the original link -- I was under the impression that some updates/fixes had been made.

Ach so, denn:
https://github.com/fenugrec/tekfwtool

[fenugrec]

https://github.com/fenugrec/tekfwtool

Hey, that's my repo  : ))
 It appears dxl's github account no longer exists (?); I had originally forked his repo to add a few minor tweaks, and the ability to compile for DOS. IIRC both our repos were 99% similar, I had 1-2 pending commits for some very trivial things.

[DC1MC]

https://github.com/fenugrec/tekfwtool

Hey, that's my repo  : ))
 It appears dxl's github account no longer exists (?); I had originally forked his repo to add a few minor tweaks, and the ability to compile for DOS. IIRC both our repos were 99% similar, I had 1-2 pending commits for some very trivial things.

Mission accomplished then , but please don't delete it as well !!!

[analogRF]

I'd be happy to get the firmware from a TDS784A (V4.1e) but the Tekfwtool doesn't seem to work for me.
I get this:

Code: [Select]

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\TekFWtool>tekfwtool -r test.bin -b 0x01000000 -l 0x400000
Unable to open device
ibsta = 0x8000 iberr = 0

E:\TekFWtool>
I'm using a Prologix USB to GPIB converter which looks like a serial port to the system. Maybe that's the problem? Does it require an NI GPIB adapter?

Yes, it only supports NI-VISA. I didn't had any other GPIB adapter except a GPIB-USB-HS at that time.

does tekfwtool work with Agilent 82357A USB-GPIB?

happy new year to all :-)

[fenugrec]

Hi,

Yes, it only supports NI-VISA.

does tekfwtool work with Agilent 82357A USB-GPIB?

The question you need to answer is "does the 82357A work with NI-VISA". I'm not sure, and it will depend on the drivers available for the 82357.

[analogRF]

Hi,

Yes, it only supports NI-VISA.

does tekfwtool work with Agilent 82357A USB-GPIB?

The question you need to answer is "does the 82357A work with NI-VISA". I'm not sure, and it will depend on the drivers available for the 82357.

as far as I know 82357A does work with NI-VISA after enabling an option in the NI software (is it NI MAX?)

so I should install NI VISA libraries on windows 7 and I should be able to use tekfwtool.exe , am I right?

[fenugrec]

so I should install NI VISA libraries on windows 7 and I should be able to use tekfwtool.exe , am I right?

Have you tested ? You maybe need part of the NI VISA SDK (if there's such a thing) to recompile tekfwtool. Should work if the newer NI drivers provide the same API