Tektronix TDS754C not communicating over GPIB in unprotected mode - Page 1
Forum section: electronics / testgear

author: amaschas
author_rank: Regular Contributor
timestamp: October 23, 2024, 05:26:36 am
content: I've got a TDS754C that I'm working on repairing, and I'm trying to get a backup of the firmware before I pull the two NVRAM ICs. I'm using an AR488 (arduino USB to GPIB) to talk to the scope, and I can communicate fine when the scope is booted normally. I can send `*IDN?` and get back:TEKTRONIX,TDS 754C,0,CF:91.1CT FV:v5.3eHowever once I switch the scope to unprotected mode it stops responding over GPIB at all. Does unprotected mode use some pre-set address that I'm not aware of, or is there something else going on here?

author: 44kgk1lkf6u
author_rank: Regular Contributor
timestamp: October 23, 2024, 01:48:01 pm
content: Unprotected mode should use whatever address is configured. Maybe you have selected the off bus option in the menu under SHIFT ➞ UTILITY ➞ System (main) ➞ I/O (pop-up) ➞ Port (main) ➞ GPIB (pop-up) ➞ Configure (main).

author: amaschas
author_rank: Regular Contributor
timestamp: October 23, 2024, 03:54:33 pm
content: Quote from: 44kgk1lkf6u on October 23, 2024, 01:48:01 pmI've confirmed that the GPIB address is 1, and that I can talk to the device in protected mode. I haven't touched the GPIB settings aside from verifying the address, and since I can communicate with the device in protected mode I assume the GPIB interface is on. I'm kind of baffled. I assume that the scope should at least respond to *IDN? in unprotected mode, right?

author: TERRA Operative
author_rank: Super Contributor
timestamp: October 23, 2024, 10:44:34 pm
content: Try doing a full factory reset.I have had similar issues in the past occasionally, but somehow I eventually got the scope to resopnd.I can't exactly remember how I got it to work, but try the reset and also make sure the time is set correctly too. It doesn't matterwhat[/] the time is set to, but I have noticed if that is corrupted then the scope can do some weird stuff.Maybe a couple reboots in unprotected mode until it responds will work too.

author: amaschas
author_rank: Regular Contributor
timestamp: October 24, 2024, 05:54:23 pm
content: Quote from: TERRA Operative on October 23, 2024, 10:44:34 pmThanks for the suggestions! Unfortunately I still haven't gotten the scope to respond in unprotected mode. I've tried the following:• Factory reset the device with this procedure:Delete all "secure" files on the scope - so waveforms stored etc.(TDS: "Utility" --> "Config" --> "Tek Secure Erase Memory" --> "OK Erase Setup & Ref Memory")Perform a factory reset (TDS: "Setup" --> "RECALL Factory Setup" --> "OK Confirm Factory init")• Cleared the error log using `error clear` and then `*cls`.• Setting the time (the time seemed ok, but I reset each of the values just to be sure).• Plugging the AR488 into the GPIB port a few seconds after starting the scope in unprotected mode.• Rebooting the device several times in unprotected mode.I'm wondering if there are any other debugging steps I could take here. Would the unprotected mode bootloader produce any output on the RS232 port that might be of help? I've been trying commands on GPIB channel 1 and 29. Are there other channels I should attempt?

author: TERRA Operative
author_rank: Super Contributor
timestamp: October 25, 2024, 08:44:45 am
content: As a last resort, if you have a chip programmer, you can just read out the chips directly after you have pulled them out then write that data straight into the new chips.(Be aware that the timekeeper chip will fail verification due to the real time clock advancing between read and write, causing a mismatch, this is expected behaviour)If you can communicate over GPIB in normal mode, it should 'just work' in unprotected mode too, I'm not sure what's up with your scope...There is a diagnostic port on the top processor board next to where the serial adapter plugs in (It's a card edge connector made as part of the PCB). with a bit of a pinout shuffle you can actually use the serial adapter board to monitor the diagnostic port (Or buy this adapter:https://www.ebay.com/sch/i.html?_nkw=tds+debug).Otherwise there are some plans available to make your own adapter:https://www.eevblog.com/forum/repair/tektronix-tds500-700-debug-konscole-interface/There's a USB one somewhere out there too. I have a design, but I have to get around to ordering boards to see if it works...Also of note, on the red DIP switch S1001 on the top board, pin 3 is for self test, all switches should be closed except for pin 3 for normal operation. If you also close pin 3, it puts the scope into an extended self test on boot. So if you are monitoring the diagnostic port, this could help find more info to see if there is a problem.

author: amaschas
author_rank: Regular Contributor
timestamp: October 26, 2024, 07:50:36 pm
content: Quote from: TERRA Operative on October 25, 2024, 08:44:45 amI just tried another (Prologix-compatible) GPIB to USB adapter I forgot I had on hand, and had the same problem, so at least I know it's not the adapter. Kind of unlikely anyway, seeing as I can communicate with the old adapter fine in unprotected mode.I think I'm about out of debugging steps with what I have on hand, so I ordered one of those boards. Hopefully I can get some useful debug output that will at least give me a hint of what is going on!

author: amaschas
author_rank: Regular Contributor
timestamp: November 02, 2024, 06:00:14 am
content: My debug board arrived today, and I have found myself in serial communication hell. Per this thread:https://www.eevblog.com/forum/testgear/console-port-debug-adapter-for-tek-tds500-tds600-and-tds700-series-scopes/the debug port on this device requires hardware RTS/CTS handshaking, and the serial to USB adapter I have does not appear to support that mode, even though the FTDI controller inside technically does. I managed to get the scope to boot with the debug interface connected by shorting RTS to CTS, but I could only receive gibberish over the serial connection in this state (the question marks and ampersands you'd expect when you set the baud port incorrectly). Interestingly, the gibberish continued even with the scope powered completely off and unplugged, which is pretty puzzling. I don't have a lot of experience with serial connections that require this mode, so I guess I'll have to do a deep dive on how it all works and see if I an get some debug output.

author: amaschas
author_rank: Regular Contributor
timestamp: November 12, 2024, 05:02:15 am
content: After a long odyssey with a DB9 breakout that claimed to do level shifting and in fact did nothing, I have successfully extracted some serial debug output from the scope. Unfortunately, my serial implementation only allows me to read from the scope at this point, and I believe the serial interface supports a few commands that might be helpful if the version on the TDS754 is anything like the TDS420 here:https://www.eevblog.com/forum/testgear/tds420-with-lost-options/.I'm also not seeing anything in the debug output that indicates a problem, but maybe someone else will spot something I haven't? Here's the output with the flash locked:Code:RUNNING FROM DRAM.DRAM test passed.Bootrom Header Checksum passed.Bootrom Total Checksum passed.BootRom Check Sum passed.Bus Error Timeout test passed.Kernel Diagnostics Complete.Calling SDM (monitor) Routine.Enabling Bus Control register. Value = 0x67IMR 1 Register test passed.Misc. Register test passed.Timer Interrupt test (Auto-Vector) passed.NVRam DSACK test passed.NVRam Write protected.Flashrom DSACK and JumpCode test passed.Flashrom Checksums passed.Bootrom Diagnostics Complete.DipSwitchValue: 0Skipping boot loader.Transferring control to FlashROM.No PCMCIA option board detected.FLOPPY: DetectedAdding 6335 symbols for standalone.CPU: 68EC040. Processor #0.Memory Size: 0x800000. BSP version 1.0.Executing Diagnostics-> Start Power-On Diag SequencehwAccountant probe routinesProbe for unexpected pending intsDsp Instr mem sizeDsp D2 mem sizeDsp D1 mem sizeDsy Vect0 mem sizeDsy Vect1 mem sizeDsy Wfm0 mem sizeDsy Wfm1 mem sizeDsy Text0 mem sizeDsy Text1 mem sizeAcq number of digitizersAcq mem sizeCpu timer interval uSecCpu Dram sizeNvRam mem sizeLimit to 1GS/sec presenceOpt Math Package presenceOpt Telecom Masks presenceOpt 3C presenceOpt 4C presenceOpt RS232/ Cent presenceOpt 1M presenceOpt 2M presenceAcq Intlv Cal Id presenceOpt TvTrig presenceOpt TvTrig indexDsy color presenceOpt floppy drive presenceOpt hard drive presenceAcq number of user channelsdspForcedBus ................... passcpuDiagD2MiscReg ............... passcpuDiagDSPIntMaskReg ........... passcpuDiagDsyAccess ............... passdsp68kMemTest .................. passcpuDiagFIFOMem ................. passdspRunVerify ................... passdspBusRequestTest .............. passdspImplicitBusAccess ........... passdspTristarMemTest .............. passdsyRastModeV0Walk .............. passdsyRastModeV1Attrib ............ passdsyWaitClock ................... passcpuDiagAllInts ................. passnvLibrariansDiag ............... passcalLibrarianDefaultCk .......... passdspForcedBus ................... passacqProcThermistor .............. passtrigGtlRegisterDiag ............ passtrigBtlRegisterDiag ............ passch1EdgeTrigDiag ................ passlineTrigDiag ................... passdlyTrigDBTRunsAfter ............ passslewrateTrigDiag ............... passtrigAttenSerialReg ............. passtrigPreampSerialReg ............ passtrigDTCSerialReg ............... passtrigExtlSerialReg .............. passtrigDacSerialReg ............... passTICountersDiag ................. passgtlBigCountersDiag ............. passtrigBtlConfidenceDiag .......... passtrigGtlCompRamDiag ............. passdigRegisterConf ................ passdigSpecialRegisterConf ......... passfpDiagConf ..................... passoptDiagPM110Reg ................ passoptDiagFloppyCacheMem .......... passoptDiagFloppyControllerIO ...... passoptDiagFloppyDrive ............. passoptRS232DuartIO ................ UNTESTEDoptRS232DuartIntLoop ........... UNTESTEDoptCentronCntrlReg ............. UNTESTEDoptTv8bitRegDiag ............... UNTESTEDoptTvShiftRegDiag .............. UNTESTEDoptTvXparentCodes .............. UNTESTEDoptTvDontCareCodes ............. UNTESTEDoptTvEdgeAndLevel .............. UNTESTEDoptTvSyncLevels ................ UNTESTEDExecuting SmalltalkhwAccountant probe routinesProbe for unexpected pending intsDsp Instr mem sizeDsp D2 mem sizeDsp D1 mem sizeDsy Vect0 mem sizeDsy Vect1 mem sizeDsy Wfm0 mem sizeDsy Wfm1 mem sizeDsy Text0 mem sizeDsy Text1 mem sizeAcq number of digitizersAcq mem sizeCpu timer interval uSecCpu Dram sizeNvRam mem sizeLimit to 1GS/sec presenceOpt Math Package presenceOpt Telecom Masks presenceOpt 3C presenceOpt 4C presenceOpt RS232/ Cent presenceOpt 1M presenceOpt 2M presenceAcq Intlv Cal Id presenceOpt TvTrig presenceOpt TvTrig indexDsy color presenceOpt floppy drive presenceOpt hard drive presenceAcq number of user channelscan't open input 'fd0:/startup.bat'errno = 0x13 (S_errno_ENODEV)Smalltalk/V Sun Version 1.12Copyright (C) 1990 Object Technology International Inc.ERRORID: 216 Internal adjustment range exceeded 1.1529 => Balance dac #4 (ID #147)As you can see, there's an issue with the Balance dac on channel 4, which is a known issue that I'm hoping to fix eventually. I'm also seeing that error about "can't open input 'fd0:/startup.bat'". But nothing relating to the GPIB interface. One other recent development with the GPIB interface in unlocked mode: it's very difficult to determine from the UI whether GPIB is active or not. Earlier today I was trying to get it to respond to *IDN? and failing to get anything back. Nothing worked until I changed the address from 1 to 2, at which point the scope started responding. Then when I changed the address back to 1, it responded on that address properly again. I''m thinking maybe changing the address resets one of the other options that prevent communication? I'm wondering if the interface is supposed to look like this, in that you can't really tell what is on or off:Notable here is the fact that the Configure OFF Bus option is selected at the bottom, but the option screen itself is adjusting the GPIB address. I really have no idea how the options on the bottom relate to the state of the selections on the side. Either way, I can get the device to respond in this mode, so that proves that both my adapter and the GPIB bus are working at least in some cases.Here's the output when I lock the flash:Code:RUNNING FROM DRAM.DRAM test passed.Bootrom Header Checksum passed.Bootrom Total Checksum passed.BootRom Check Sum passed.Bus Error Timeout test passed.Kernel Diagnostics Complete.Calling SDM (monitor) Routine.Enabling Bus Control register. Value = 0x67IMR 1 Register test passed.Misc. Register test passed.Timer Interrupt test (Auto-Vector) passed.NVRam DSACK test passed.+12V applied to Flashroms, NVRam NOT WRITE ProtectedFlashrom Programming Voltage is ON.Cannot transfer control to Flashrom.Transferring control to the SDM (monitor).I can't see anything pertinent that would relate to GPIB not responding, but maybe someone else can see something I don't.

author: TERRA Operative
author_rank: Super Contributor
timestamp: November 12, 2024, 06:27:29 am
content: I think you can safely ignore the "can't open input 'fd0:/startup.bat'' error. That would most probably be related to use of a boot disk for enabling options, updating firmware, etc using the floppy disk.Kind of like when an older PC checks for a boot disk before it goes on to load the pre-installed OS after a short timeout.I'll have to check how the GPIB settings are set in my scopes tonight, I can't remember off-hand.

author: 44kgk1lkf6u
author_rank: Regular Contributor
timestamp: November 12, 2024, 03:48:19 pm
content: The screenshot shows that the off bus option is selected. The oscilloscope is not supposed to respond on GPIB in this state. You have to make sure the "Talk/Listen" option is highlighted instead.

author: TERRA Operative
author_rank: Super Contributor
timestamp: November 12, 2024, 04:00:25 pm
content: Here are my settings that work for me with an Agilent 82357B USB-GPIB adapter, and a National Instruments USB-GPIB-HS adapter (I used the NI adapter to capture the screen shot).As 44kgk1lkf6u mentioned, make sure 'Talk/Listen' is selected at top right. I also suggest setting the GPIB address to 1 (or not zero at least), the Keysight Connection Expert software didn't care, but the absolutely bloated mess of total crap that is the National Instruments software package only worked when I set the address from 0 to 1.

author: amaschas
author_rank: Regular Contributor
timestamp: November 13, 2024, 05:37:38 am
content: I still don't really understand how the GPIB settings work, but since my scope is able to communicate in unlocked mode I figure the port must be active and not set to talk only? Here are the settings I'm actually using, just uploaded that previous image as an example of how confusing that settings screen is.Another interesting development. I ordered am NI GPIB/USB adapter a while back and it showed up. I started poking around with the NI software, and as expected when I scan for instruments in locked mode it successfully finds the instrument on address 1. However, when I toggle the unlock switch and scan for instruments, the NI software picks up an instrument on address 29 what will not respond to *IDN?. I have read suggestions elsewhere that some of these scopes use different addresses for GPIB in unlocked mode (this guy here for instance:https://www.eevblog.com/forum/repair/tekfwtool-for-tds540c-firmware-upgrade/msg2845956/#msg2845956), but since the instrument still is not responding to *IDN? I'm not sure whether its actually finding anything? Here's what I see trying to connect to the instrument.I'm wondering if this could be an issue with corrupted firmware? I have a parallel effort going to extract the firmware and calibration data using the floppy disk tool, which appears to have succeeded but as I have don't have any machines with an old enough OS to read a floppy without a media descriptor byte, I'm trying to get my hands on an old laptop that can run Windows XP, which at the very least comes with the tool that can add the MDB. Once I have a firmware backup I'm confident in I'm going to pull the two NRAMs off the board and solder in headers, and I'll maybe try restoring the firmware. My understand is that the scope boots from some kind of bootloader in unlocked mode however, and I don't know if the firmware has anything to do with that.

author: picburner
author_rank: Frequent Contributor
timestamp: November 13, 2024, 07:44:31 am
content: An explanation for the lack of response to the *idn? command could be this (taken from the "C" code of the Tektool utility):Code:#if 0/* Test GPIB communication *//* WARNING - DOES NOT WORK WHEN IN NVRAM-UNPROTECTED MODE ON CERTAIN MODELS! */ibwrt (Dev, "*IDN?", 5L);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to write to device");return 1;}ibrd (Dev, buf, 101);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to read data from device");return 1;}#endifIf your firmware is corrupt you will be warned during boot, there is an integrity check for this.

author: TERRA Operative
author_rank: Super Contributor
timestamp: November 13, 2024, 03:17:51 pm
content: If you need clean firmware dumps from the NVRAMs, I can probably sort something from one of my spare scopes and send through the files.

author: amaschas
author_rank: Regular Contributor
timestamp: November 13, 2024, 04:36:16 pm
content: Quote from: picburner on November 13, 2024, 07:44:31 amInteresting, I did actually try a few other commands, including the memory read and write commands requires to backup the firmware or set options and the scope didn't respond, but it's notable that there is a precedent for the scope not responding to certain commands when unlocked. I guess the big question I still have is: what determines the behavior of the scope in unlocked mode? Is it a firmware thing, or is there a bootloader stored somewhere else entirely?Another interesting bit of information, my scope comes with the 5.3e firmware version, which is the latest version of the firmware for the 754C and is apparently rarely found on this model of scope.

author: picburner
author_rank: Frequent Contributor
timestamp: November 13, 2024, 05:49:13 pm
content: According tothis documentthe latest firmware release for a 754C would be the 5.11But maybe it depends on the hardware version....

author: amaschas
author_rank: Regular Contributor
timestamp: November 13, 2024, 06:09:38 pm
content: Quote from: picburner on November 13, 2024, 05:49:13 pmOh that's good to know, I was relying on this page:https://w140.com/tekwiki/wiki/TDS754.Maybe a firmware upgrade is in order?Quote from: TERRA Operative on November 13, 2024, 03:17:51 pmThat would be super useful, thank you! Do you happen to know what version(s) of the firmware you have?

author: TERRA Operative
author_rank: Super Contributor
timestamp: November 13, 2024, 10:22:56 pm
content: I have a big collection of various firmware, including v5.3e (but not the NVSRAM that holds user data strangely. I do have plans to rip the data from all the chips as I sell these scopes off, to complete my library though) ripped using the Tektools to dump via GPIB.So, I should have an actual scope here for real that I can dump the both the Firmware and NVSRAM directly from the chips themselves without much problems.Also regarding a bootloader, there is a UV EPROM chip with a sticker on top on the Processor board. AFAIK, that contains the bootloader. I have found them to be as reliable as UV EPROM chips tend to be. That is to say, I've never had an issue with one before.If you can tell me the part number on the sticker of your EPROM, I can see if I have one here to rip (or even pull from a spare parts board if I have one of the correct type..)

author: amaschas
author_rank: Regular Contributor
timestamp: November 14, 2024, 12:28:22 am
content: Quote from: TERRA Operative on November 13, 2024, 10:22:56 pmI couldn't find anything that look very obviously like an EEPROM on the processor board, but took some photos of the board and anything on the board bearing a sticker.

author: picburner
author_rank: Frequent Contributor
timestamp: November 14, 2024, 06:58:56 am
content: U133 should be the "kernel rom" containing the firmware with basic diagnostic tests and the code to update the Flash memory.The code contained in U133 is the one that works in "unprotected" mode.If all the tests are ok it passes the control to the firmware contained in the main Flash memory (5.3e in your case), firmware contained in the two Intel memories side by side, at the top, in your first photo.U17 I don't know what it is.The hardware of your scope seems to me to be one of the latest ever produced of this series, nothing to do with my ancient TDS784C.

author: TERRA Operative
author_rank: Super Contributor
timestamp: November 14, 2024, 11:36:21 am
content: Yeah, the flash chips are interesting. Usually the firmware is kept in one of the Dallas chips IIRC, the other holds user settings, unlocked options and saved waveforms.Unless the intel chips are used for the saved waveforms etc?

author: picburner
author_rank: Frequent Contributor
timestamp: November 14, 2024, 07:17:43 pm
content: The firmware, the software that governs the machine, has always resided on Flash memory in the entire TDSxxx family.Dallas chips have always contained user data only, RTC, options, and all the system an user variables that need to be kept in memory even when the machine is turned off.It is not for nothing that when looking at the scope memory map you will see that the Flash memory uses a 32-bit bus (Hi speed), while the kernel eprom and the NVRAM use an 8-bit bus with slower accesses.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 03, 2024, 07:13:30 am
content: Quote from: amaschas on November 13, 2024, 05:37:38 amHello@amashas, I'm posting for the first time on your thread after you contact me by private mail. You are asking about GPIB address 29 and quoting an old post from me (this guy) end of 2019 where I was on my learning curve with GPIB and repair my TDS540C. Since then i've made lot repairs, modification, un-bricking through the re-use of the initial tekfwtool collected by swedish member@raggesand german member@madaomore than 10 TDS500/700/C/DIn fact there are still some remaining issues which have been fixed (C programming of tektool and tekfwtool) but I did not upload my repo on github which is forked from@raggesinitial github, see the actual fileshere on my github account.First is first, it is normal that when you un-protect switch then the GIPB address will be 29 instead of 1If you want to dump your EEPROM via GPIB, one method is to run getcaldata with protected switch from herehttps://github.com/tantratron/tektools/tree/master/getcaldatathen notice the source file with GPIB address 1Code:* Assign a unique identifier to the device and store in the variable* Dev. If the ERR bit is set in ibsta, call GPIBCleanup with an* error message. Otherwise, the device handle, Dev, is returned and* is used in all subsequent calls to the device.*/#define BDINDEX 0 // Board Index#define PRIMARY_ADDR_OF_DMM 1 // Primary address of device#define NO_SECONDARY_ADDR 0 // Secondary address of device#define TIMEOUT T10s // Timeout value = 10 seconds#define EOTMODE 1 // Enable the END message#define EOSMODE 0 // Disable the EOS modeFILE *outfile;int f;#if 0unsigned long addr;// addr = 0x00040000L; /* CAL data base address on TDS5xxB,6xxA,7xxA*/addr = 262144; /* CAL data base address on TDS5xxB,6xxA,7xxA*/#endifprint_version();Dev = ibdev (BDINDEX, PRIMARY_ADDR_OF_DMM, NO_SECONDARY_ADDR,TIMEOUT, EOTMODE, EOSMODE);if (ibsta & ERR){GPIBCleanup(Dev, "Unable to open device");return 1;}However to use tektool or tekfwtool, you need to un-protect NVRAM and for sure, it will use GPIB address of 29 (see extract of the C code from tekfwtool)Code:#define DEFAULT_GPIBADDR 29..../////....int main(int argc, char **argv){uint32_t len, addr, base = 0, length = 0;int devaddr = DEFAULT_GPIBADDR;char c;....////...Dev = ibdev(0, devaddr, 0, T100s, 1, 0);if (ibsta & ERR) {printf("Unable to open device\nibsta = 0x%x iberr = %d\n",ibsta, iberr);goto bad_exit;}So as a first step, I recommend using National Instruments USB-GPIB (only legacy model built in Hungary) because chinese clone are detected by NI driver and blocked. The prologix had some issues even if it seems to work, personnally I prefer to use real NI equipment which works fine plsu in my case (use of macOS) works super fine.If you confirm that GPIB is 29 when un-protect mode then you are fine so we will try finding the possible root cause of your problem. It is normal that when in protected mode (address 29), the GPIB query of*IDN?willnotwork.Albert

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 03, 2024, 07:16:40 am
content: Quote from: picburner on November 13, 2024, 05:49:13 pmNo the lastest firmware is 5.3 and works fine, in fact above document does stateTDS540C,F/W,5.3

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 03, 2024, 07:20:30 am
content: Quote from: picburner on November 14, 2024, 06:58:56 amThis is totally correct except the EPROM chip is U1331 but depending on the CPU board (they can be used on C serie or D serie except you need to match the firmware versus the acquisition board C serie or D serie), the Kernel version is different, same for the tek ASIC (chip U1) acting as a 68020 to 68040 translator.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 03, 2024, 10:27:04 am
content: Quote from: amaschas on November 14, 2024, 12:28:22 amI've looked at your 3 photos from your CPU board compared against my own data base compiled after dealing with more than ten TDS500/700/C/D oscilloscopes.With C/D serie, there are early model CPU board and late model CPU board so the firmware of these chips (U1331 U17 U1) are not the same. One reason being the DRAM used to be 5V but later sourcing problem so tektronix used 3.3V DRAM => the firmwares had to be changed on 3 chips plus they added an LDOYour board is legit, namely the 3 chips have respectively correct firmware version 163-0692-00 163-0693-00 and 163-0790-00

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 04, 2024, 05:19:58 am
content: P.S. You might consider reading attentively this topic depending on late C/D or early C/D modelshttps://www.eevblog.com/forum/repair/tektronix-tdsxxx-tektool-tekfwtool-legal-modification/andhttps://www.eevblog.com/forum/repair/tekfwtool-for-tds540c-firmware-upgrade/msg4619995/#msg4619995

author: amaschas
author_rank: Regular Contributor
timestamp: December 06, 2024, 12:30:07 am
content: Quote from: Tantratron on December 03, 2024, 07:13:30 amThis was the key thing I was missing, thank you so much! I had 3 different GPIB adapters including the NI one, and but the fact that tektool didn't work with the other two I had convinced me that the issue was with the scope, and the fact that the scope didn't respond to *IDN? in unlocked mode seemed to confirm that. I had also tried the options unlock process with the scope in unlocked mode as documented here:https://www.eevblog.com/forum/testgear/hackingupgrading-old-scope-(tds754d)/but wasn't able to get any response from any of those GPIB commands. But I just tried using tektool with the NI adapter and I was able to connect to the scope and backup the NVRAM, firmware and EEPROM data with the base tektool (not tekfwtool).I do wonder now why I wasn't able to unlock any of the options. Using the NIVISA software, when I try to send any command like PASSWORD "PITBULL", the interface just hangs for several seconds and just times out.Thanks for the links to the threads on the different scope models, I will take a look and absorb.

author: TERRA Operative
author_rank: Super Contributor
timestamp: December 06, 2024, 03:49:38 am
content: Send: PASSWORD PITBULLNot: PASSWORD "PITBULL"

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 06, 2024, 05:03:09 am
content: Quote from: amaschas on December 06, 2024, 12:30:07 amBesides the superb NI adapter which works cross-platform (Windows, Linux and macOS), some members reported the tekfwtools to work fine with Agilent 82357B GPIB adapter. I do not have one because the Agilent is not macOS compatible plus the NI model (if made in Hungary) is really awesome so I did purchase few of these in stock.

author: amaschas
author_rank: Regular Contributor
timestamp: December 07, 2024, 11:30:26 pm
content: Quote from: TERRA Operative on December 06, 2024, 03:49:38 amThis is what I'm trying with the NI adapter with unlock option 1M:I've tried both the "query" and "write" buttons with the commands, and I've tried it a few times, but 1M remains stubbornly locked. I get that timeout with pretty much any command I try, though of course tektool works so there must be some commands that do function in this mode.Interesting, I see this little block of code in tektool:Code:/* Only needed in normal running mode, not needed when running in bootloader mode(with scope booted with NVRAM Protection rocker switch in Unprotected position) *//* send first TEKTRONIX Password fr TDS5xxB/7xxA models to allow memory dump *///ibwrt (Dev, "PASSWORD PITBULL", 17L);ibwrt (Dev, "PASSWORD PITBULL", 16L);I'm not sure if this just applies to the commented line, or to the password command in general?

author: TERRA Operative
author_rank: Super Contributor
timestamp: December 08, 2024, 06:54:38 am
content: I let the scope boot normally, then flip the protection switch and then send the unlock commands.Then flick the switch back to its normal position and reboot.

author: amaschas
author_rank: Regular Contributor
timestamp: December 09, 2024, 05:33:00 pm
content: Quote from: TERRA Operative on December 08, 2024, 06:54:38 amThat did it! specifically used the write command rather than the query command, and when I booted back up 1M was enabled. Thanks so much for all your help!

author: TERRA Operative
author_rank: Super Contributor
timestamp: December 10, 2024, 04:05:44 am
content: Nice.Also, you can activate options 2C and 2F without having to add any additional hardware if they are not already acivated.

author: amaschas
author_rank: Regular Contributor
timestamp: December 11, 2024, 05:22:05 am
content: Quote from: TERRA Operative on December 10, 2024, 04:05:44 amAwesome, just went and did that, thanks for the heads up!I'm now onto tackling the hardware problems affecting channel 4. I thought the first one was going to be straightforward:Code:diagnostic test failure, digDataFormatDiag1MMem, ERROR!!in demux 200 ,i= 9 memBaseAdr 0x7380014= data = ffff8001, expectedData = 0"I believe that indicates an issue with SRAM IC U210, which I've actually gone ahead and replaced, but still seeing the error. I'm ordered a socket that will allow me to test the SRAM I pulled from the device to see if its still good, and then I'll probably systematically go through the ICs in the demux 200 range until I find a bad one.The second error I can't find a lot of info about:Code:Internal adjustment range exceeded, 1.0916 => Balance dac #4 (ID #147)"Though the general advice I've seen around DAC errors is to hit the ICs with a bit of hot air in case there's a solder joint that's gone bad over the years. Not really sure if the balance DAC is distinct from the regular DAC either. But one thing at a time I suppose.Might also be worth making a new topic about these. I've noticed that its tricky to find information when its buried in a thread about something else entirely, and I'm hoping this odyssey can be useful to others going down this road.

author: Tantratron
author_rank: Frequent Contributor
timestamp: December 11, 2024, 08:12:35 am
content: Quote from: amaschas on December 11, 2024, 05:22:05 amYes indeed, best to start a new topic to avoid confusion or mixed cross information... GPIB is one topic, acquisition board DAC and SRAM another topicYou might first check eventually other threads, the issue of DAC/SRAM has been tackled by previous members.