TDS 744A (& friends) firmware reverse engineering - Page 1
Forum section: electronics / testgear

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 22, 2017, 08:12:07 pm
content: 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 thew140 wikibut I'm not sure where it would fit in on there.My main interest is the internal service console port (seehttps://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/yEnTKHwGlook at, for example, the familiar "libManagerWordAtPut" entries and related entries.These are also intriguing:Code:_enableBackdoor 0x011c70d6 text 18641110_checkBackDoor 0x011c7166 text 18641254I 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 ?

author: dxl
author_rank: Regular Contributor
timestamp: March 22, 2017, 09:59:44 pm
content: Here you go:https://stackframe.org/tekfwtool/https://stackframe.org/tektool.shtml

author: snoopy
author_rank: Frequent Contributor
timestamp: March 23, 2017, 01:00:13 am
content: Quote from: dxl on March 22, 2017, 09:59:44 pmI can't seem to download anything from that site. Also what USB to GPIB interface do you recommend ?cheers

author: Jwalling
author_rank: Unknown
timestamp: March 23, 2017, 10:14:40 am
content: The 784D and 784C firmware is here:http://www.ko4bb.com/getsimple/index.php?id=manualsPut TDS784D or TDS784C in the search box.

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 24, 2017, 12:32:31 am
content: @dxl , @Jwalling, thanks ! for some reason I didn't even think of checking KO4BB. Interesting that there are no 744A dumps though.

author: Jay_Diddy_B
author_rank: Super Contributor
timestamp: March 24, 2017, 01:27:49 am
content: Hi,I suspect the 744A, 754A and 784A all use the same firmware ;-)Jay_Diddy_B

author: dxl
author_rank: Regular Contributor
timestamp: March 24, 2017, 10:37:45 am
content: Quote from: fenugrec on March 24, 2017, 12:32:31 amWell, the reason is that i uploaded the dumps when i wrote the tekfwtool. And i simply didn't had a TDS744

author: dxl
author_rank: Regular Contributor
timestamp: March 24, 2017, 10:39:40 am
content: Quote from: Jay_Diddy_B on March 24, 2017, 01:27:49 amNot 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.

author: andy2000
author_rank: Frequent Contributor
timestamp: March 24, 2017, 03:04:40 pm
content: 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.

author: dxl
author_rank: Regular Contributor
timestamp: March 24, 2017, 06:48:13 pm
content: Quote from: andy2000 on March 24, 2017, 03:04:40 pmI guess you're right - i think i tried to upgrade from 6.6e to 7.2e at that time.

author: james_s
author_rank: Super Contributor
timestamp: March 24, 2017, 07:49:42 pm
content: 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.

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 24, 2017, 08:07:10 pm
content: 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:ringBell( ding !! I love how these have a nice bell sound instead of the simpler piezo buzzer they could've chosen instead)Code:HWADumpOptValuesHWADumpCpuValuesHWADumpSysValues

author: james_s
author_rank: Super Contributor
timestamp: March 24, 2017, 08:55:01 pm
content: 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.

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 25, 2017, 12:21:32 pm
content: Quote from: james_s on March 24, 2017, 08:55:01 pmI 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.

author: dxl
author_rank: Regular Contributor
timestamp: March 25, 2017, 03:37:27 pm
content: Quote from: fenugrec on March 25, 2017, 12:21:32 pmThere 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.exeandhttps://stackframe.org/tekfwtool/target.bin

author: andy2000
author_rank: Frequent Contributor
timestamp: March 25, 2017, 09:56:12 pm
content: Quote from: dxl on March 25, 2017, 03:37:27 pmI just get this when I try to download those files:ForbiddenYou don't have permission to access /tekfwtool/tekfwtool.exe on this server.Apache/2.4.18 (Ubuntu) Server at stackframe.org Port 443

author: dxl
author_rank: Regular Contributor
timestamp: March 25, 2017, 10:24:57 pm
content: Quote from: andy2000 on March 25, 2017, 09:56:12 pmWhoops, my fault. Should be fixed now.

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 25, 2017, 10:56:30 pm
content: Quote from: dxl on March 25, 2017, 03:37:27 pmOh 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: March 26, 2017, 11:42:57 am
content: Quote from: dxl on March 25, 2017, 10:24:57 pmAvast is flagging a DRep virus when I try and download the exe. Is this a false positive ?cheers

author: 1Ghz
author_rank: Unknown
timestamp: March 26, 2017, 12:10:44 pm
content: Quote from: snoopy on March 26, 2017, 11:42:57 amSeems to be a false positive. See link below.https://forum.avast.com/index.php?topic=163221.msg1164286#msg1164286

author: snoopy
author_rank: Frequent Contributor
timestamp: March 26, 2017, 12:28:36 pm
content: Quote from: 1Ghz on March 26, 2017, 12:10:44 pmDoes anyone know how I can bypass this so I can download the file ?cheers

author: Jwalling
author_rank: Unknown
timestamp: March 26, 2017, 01:03:58 pm
content: Quote from: snoopy on March 26, 2017, 11:42:57 amNorton reports this:https://us.norton.com/security_response/writeup.jsp?docid=2010-051308-1854-99Virustotal sees nothing wrong with it. 0/61https://www.virustotal.com/en/file/40b810b6dd88b8a65b9b5f5138c7669fc0f81222ebc58e463de0d0fdd19f2f21/analysis/1490533278/You should be able to temporarily disable your virus protection.

author: snoopy
author_rank: Frequent Contributor
timestamp: March 27, 2017, 12:04:07 am
content: Quote from: Jwalling on March 26, 2017, 01:03:58 pmYes 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

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 27, 2017, 08:22:24 pm
content: For anyone having problems downloading the .exe, I don't think it would be very hard to compile from source.

author: Jwalling
author_rank: Unknown
timestamp: March 29, 2017, 02:44:27 pm
content: 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:Microsoft Windows XP [Version 5.1.2600](C) Copyright 1985-2001 Microsoft Corp.E:\TekFWtool>tekfwtool -r test.bin -b 0x01000000 -l 0x400000Unable to open deviceibsta = 0x8000 iberr = 0E:\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?

author: dxl
author_rank: Regular Contributor
timestamp: March 29, 2017, 06:35:06 pm
content: Quote from: Jwalling on March 29, 2017, 02:44:27 pmYes, it only supports NI-VISA. I didn't had any other GPIB adapter except a GPIB-USB-HS at that time.

author: james_s
author_rank: Super Contributor
timestamp: March 29, 2017, 08:04:32 pm
content: 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.

author: alm
author_rank: Super Contributor
timestamp: March 29, 2017, 08:29:27 pm
content: 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).

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 29, 2017, 10:08:47 pm
content: Quote from: james_s on March 29, 2017, 08:04:32 pmHaha "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 sigrokhttp://sigrok.org/wiki/Gpibgrokbut 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 ?

author: Jwalling
author_rank: Unknown
timestamp: March 30, 2017, 05:19:53 pm
content: Quote from: fenugrec on March 29, 2017, 10:08:47 pmI 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?

author: james_s
author_rank: Super Contributor
timestamp: March 30, 2017, 06:24:11 pm
content: Quote from: fenugrec on March 29, 2017, 10:08:47 pmWell 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.

author: fenugrec
author_rank: Frequent Contributor
timestamp: April 03, 2017, 12:10:33 am
content: Quote from: Jwalling on March 30, 2017, 05:19:53 pmMostly -- yes you can dump the firmware through the console port, but it's *painfully* slow, so my goal is to find a matching set ofa) 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: April 03, 2017, 12:38:39 am
content: Would this GPIB USB interface be suitable ?http://www.ebay.com/itm/UG01-USB-to-GPIB-Controller-Made-in-USA-/282245791693?

author: james_s
author_rank: Super Contributor
timestamp: April 03, 2017, 12:59:30 am
content: It's a lot cheaper to build one, this is what I havehttp://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.htmlI 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.

author: smartboy123
author_rank: Newbie
timestamp: April 12, 2017, 12:49:40 am
content: Quote from: dxl on March 25, 2017, 03:37:27 pmI 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 0x10tektool -w firmware.bin -b 0x01000000 -l 0x400000The 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?

author: smartboy123
author_rank: Newbie
timestamp: April 12, 2017, 01:56:54 am
content: 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?

author: smartboy123
author_rank: Newbie
timestamp: April 12, 2017, 02:43:19 am
content: 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?

author: capt bullshot
author_rank: Super Contributor
timestamp: April 12, 2017, 05:48:48 am
content: Quote from: smartboy123 on April 12, 2017, 12:49:40 amThere'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)

author: smartboy123
author_rank: Newbie
timestamp: April 12, 2017, 07:10:18 am
content: Using "-p" option, my dead device was updated to newest firmware v7.4e now.Thank you very much.

author: dxl
author_rank: Regular Contributor
timestamp: April 13, 2017, 10:38:02 am
content: 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.

author: kc7gr-15
author_rank: Contributor
timestamp: October 03, 2017, 05:11:43 am
content: 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!

author: Jwalling
author_rank: Unknown
timestamp: October 03, 2017, 09:48:07 am
content: Quote from: kc7gr-15 on October 03, 2017, 05:11:43 amI 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.

author: kc7gr-15
author_rank: Contributor
timestamp: October 05, 2017, 04:46:40 pm
content: 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.

author: Jwalling
author_rank: Unknown
timestamp: October 05, 2017, 05:21:10 pm
content: Quote from: kc7gr-15 on October 05, 2017, 04:46:40 pmOuch, 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!

author: kc7gr-15
author_rank: Contributor
timestamp: October 05, 2017, 08:19:54 pm
content: 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).

author: kc7gr-15
author_rank: Contributor
timestamp: October 07, 2017, 07:13:02 pm
content: 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).

author: kc7gr-15
author_rank: Contributor
timestamp: October 14, 2017, 07:51:58 am
content: 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=140017Just 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

author: Jwalling
author_rank: Unknown
timestamp: October 14, 2017, 09:54:06 am
content: Quote from: kc7gr-15 on October 14, 2017, 07:51:58 amThat'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...

author: kc7gr-15
author_rank: Contributor
timestamp: October 14, 2017, 05:59:23 pm
content: 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).

author: Scratch.HTF
author_rank: Regular Contributor
timestamp: October 16, 2017, 08:14:43 am
content: How about emulating the oscilloscope with MAME?This is one way of finding out how to unlock software options e.g. FFT etc.

author: charlyd
author_rank: Frequent Contributor
timestamp: October 16, 2017, 06:37:50 pm
content: 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.

author: smartboy123
author_rank: Newbie
timestamp: October 19, 2017, 01:08:15 am
content: Quote from: dxl on April 13, 2017, 10:38:02 amYour document is still with typo error, I check just now

author: charlyd
author_rank: Frequent Contributor
timestamp: November 10, 2017, 07:47:12 pm
content: typo error for what?

author: fenugrec
author_rank: Frequent Contributor
timestamp: November 24, 2017, 09:20:28 pm
content: 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 upEach 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.I am now GPIB-enabled, and also I have just found dxl's github repo : )https://github.com/sschnelle/tekfwtool

author: fenugrec
author_rank: Frequent Contributor
timestamp: January 13, 2018, 12:56:08 am
content: Finally, I have dumped my TDS744A v1.1e firmware and NVRAM areas.For the moment they're in "recent uploads" on KO4BBhttp://www.ko4bb.com/getsimple/index.php?id=manuals&dir=07_Recent_UploadsI 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

author: fenugrec
author_rank: Frequent Contributor
timestamp: February 12, 2018, 09:48:08 pm
content: 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.

author: james_s
author_rank: Super Contributor
timestamp: February 12, 2018, 10:07:17 pm
content: 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.

author: fenugrec
author_rank: Frequent Contributor
timestamp: March 13, 2018, 07:55:48 pm
content: 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 headerYay, the main ROM has a header with meaningful metadata !It looks like this :Code:// the sizeof() for this is 0x2C (determined by checksum code in kernel ROM)struct flashhdr_short {u8jmp_trampoline;// "nop", then "jmp _romInit"u32cksum_body_start;//ptr to beginning of body area to sumu32idata_start;// initial vals for _sdata in RAMu32sdata;//addr of _sdata in RAMu32bss_start;//also end of _sdata areau32cksum_body;//32-bit checkum of body areau8unknown;u8padding;//always 0xFF bytes ?u16cksum_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 tableIt took me a while to figure all this out, but here's some information that willmake the process easier when analyzing a new ROM.ROM format : as we know the main ROM is mapped at 0x0100 0000 in the addressspace. 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 tableis the golden key : it associates a readable name to many, many functions and variables.Each symbol item looks like this :Code:struct sym_item {u32unknown_0;//always 0 ?u32pName;//point to stringu32pItem;//point to actual item (function or variable)u8type;//not 100% sure. 5 = code, 7 = idata, 9 = bss data ?u8unknown_1;//always 0 ?};Here's an example :Code: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: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 | 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 !

author: ZL1CVD
author_rank: Regular Contributor
timestamp: May 11, 2018, 11:23:05 am
content: 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.

author: KE5FX
author_rank: Super Contributor
timestamp: September 01, 2018, 08:52:29 pm
content: Looks like the tekfwtool Github page gibt's nicht mehr.Is there an updated link somewhere?

author: DC1MC
author_rank: Super Contributor
timestamp: September 01, 2018, 09:23:26 pm
content: Quote from: KE5FX on September 01, 2018, 08:52:29 pmAußerhalb von Github gibt's Leben auch:https://stackframe.org/tekfwtool/

author: KE5FX
author_rank: Super Contributor
timestamp: September 01, 2018, 09:27:01 pm
content: Quote from: DC1MC on September 01, 2018, 09:23:26 pmTrue, but that's just the original link -- I was under the impression that some updates/fixes had been made.

author: DC1MC
author_rank: Super Contributor
timestamp: September 01, 2018, 10:11:03 pm
content: Quote from: KE5FX on September 01, 2018, 09:27:01 pmAch so, denn:https://github.com/fenugrec/tekfwtool

author: fenugrec
author_rank: Frequent Contributor
timestamp: September 03, 2018, 01:29:58 am
content: Quote from: DC1MC on September 01, 2018, 10:11:03 pmHey, 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.

author: DC1MC
author_rank: Super Contributor
timestamp: September 03, 2018, 03:58:34 am
content: Quote from: fenugrec on September 03, 2018, 01:29:58 amMission accomplished then, but please don't delete it as well !!!

author: analogRF
author_rank: Super Contributor
timestamp: December 31, 2019, 07:28:36 pm
content: Quote from: dxl on March 29, 2017, 06:35:06 pmdoes tekfwtool work with Agilent 82357A USB-GPIB?happy new year to all :-)

author: fenugrec
author_rank: Frequent Contributor
timestamp: December 31, 2019, 09:40:40 pm
content: Hi,Quote from: analogRF on December 31, 2019, 07:28:36 pmThe 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.

author: analogRF
author_rank: Super Contributor
timestamp: December 31, 2019, 11:27:13 pm
content: Quote from: fenugrec on December 31, 2019, 09:40:40 pmas 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?

author: fenugrec
author_rank: Frequent Contributor
timestamp: January 20, 2020, 07:04:39 pm
content: Quote from: analogRF on December 31, 2019, 11:27:13 pmHave 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