Author Topic: Tektronix TDS754C not communicating over GPIB in unprotected mode  (Read 2818 times)

0 Members and 1 Guest are viewing this topic.

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
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.3e

However 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?
 

Offline 44kgk1lkf6u

  • Regular Contributor
  • *
  • Posts: 76
  • Country: 00
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #1 on: October 23, 2024, 01:48:01 pm »
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).
 
The following users thanked this post: amaschas

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #2 on: October 23, 2024, 03:54:33 pm »
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).

I'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?
« Last Edit: October 23, 2024, 05:46:14 pm by amaschas »
 

Online TERRA Operative

  • Super Contributor
  • ***
  • Posts: 3172
  • Country: jp
  • Voider of warranties
    • Near Far Media Youtube
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #3 on: October 23, 2024, 10:44:34 pm »
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 matter what[/] 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.
Where does all this test equipment keep coming from?!?

https://www.youtube.com/NearFarMedia/
 
The following users thanked this post: amaschas

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #4 on: October 24, 2024, 05:54:23 pm »
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 matter what[/] 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.

Thanks 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?
 

Online TERRA Operative

  • Super Contributor
  • ***
  • Posts: 3172
  • Country: jp
  • Voider of warranties
    • Near Far Media Youtube
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #5 on: October 25, 2024, 08:44:45 am »
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.
« Last Edit: October 25, 2024, 08:50:41 am by TERRA Operative »
Where does all this test equipment keep coming from?!?

https://www.youtube.com/NearFarMedia/
 
The following users thanked this post: amaschas

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #6 on: October 26, 2024, 07:50:36 pm »
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.

I 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!
 

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #7 on: November 02, 2024, 06:00:14 am »
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.
 

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #8 on: November 12, 2024, 05:02:15 am »
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: [Select]
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 = 0x67
        IMR 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: 0


Skipping boot loader.
Transferring control to FlashROM.

No PCMCIA option board detected.
FLOPPY: Detected

Adding 6335 symbols for standalone.


CPU: 68EC040.  Processor #0.
Memory Size: 0x800000.  BSP version 1.0.

Executing Diagnostics
-> Start Power-On Diag Sequence
hwAccountant probe routines
  Probe for unexpected pending ints
  Dsp Instr mem size
  Dsp D2 mem size
  Dsp D1 mem size
  Dsy Vect0 mem size
  Dsy Vect1 mem size
  Dsy Wfm0 mem size
  Dsy Wfm1 mem size
  Dsy Text0 mem size
  Dsy Text1 mem size
  Acq number of digitizers
  Acq mem size
  Cpu timer interval uSec
  Cpu Dram size
  NvRam mem size
  Limit to 1GS/sec presence
  Opt Math Package presence
  Opt Telecom Masks presence
  Opt 3C presence
  Opt 4C presence
  Opt RS232/ Cent presence
  Opt 1M presence
  Opt 2M presence
  Acq Intlv Cal Id presence
  Opt TvTrig presence
  Opt TvTrig index
  Dsy color presence
  Opt floppy drive presence
  Opt hard drive presence
  Acq number of user channels
dspForcedBus ................... pass
cpuDiagD2MiscReg ............... pass
cpuDiagDSPIntMaskReg ........... pass
cpuDiagDsyAccess ............... pass
dsp68kMemTest .................. pass
cpuDiagFIFOMem ................. pass
dspRunVerify ................... pass
dspBusRequestTest .............. pass
dspImplicitBusAccess ........... pass
dspTristarMemTest .............. pass
dsyRastModeV0Walk .............. pass
dsyRastModeV1Attrib ............ pass
dsyWaitClock ................... pass
cpuDiagAllInts ................. pass
nvLibrariansDiag ............... pass
calLibrarianDefaultCk .......... pass
dspForcedBus ................... pass
acqProcThermistor .............. pass
trigGtlRegisterDiag ............ pass
trigBtlRegisterDiag ............ pass
ch1EdgeTrigDiag ................ pass
lineTrigDiag ................... pass
dlyTrigDBTRunsAfter ............ pass
slewrateTrigDiag ............... pass
trigAttenSerialReg ............. pass
trigPreampSerialReg ............ pass
trigDTCSerialReg ............... pass
trigExtlSerialReg .............. pass
trigDacSerialReg ............... pass
TICountersDiag ................. pass
gtlBigCountersDiag ............. pass
trigBtlConfidenceDiag .......... pass
trigGtlCompRamDiag ............. pass
digRegisterConf ................ pass
digSpecialRegisterConf ......... pass
fpDiagConf ..................... pass
optDiagPM110Reg ................ pass
optDiagFloppyCacheMem .......... pass
optDiagFloppyControllerIO ...... pass
optDiagFloppyDrive ............. pass
optRS232DuartIO ................ UNTESTED
optRS232DuartIntLoop ........... UNTESTED
optCentronCntrlReg ............. UNTESTED
optTv8bitRegDiag ............... UNTESTED
optTvShiftRegDiag .............. UNTESTED
optTvXparentCodes .............. UNTESTED
optTvDontCareCodes ............. UNTESTED
optTvEdgeAndLevel .............. UNTESTED
optTvSyncLevels ................ UNTESTED
Executing Smalltalk
hwAccountant probe routines
  Probe for unexpected pending ints
  Dsp Instr mem size
  Dsp D2 mem size
  Dsp D1 mem size
  Dsy Vect0 mem size
  Dsy Vect1 mem size
  Dsy Wfm0 mem size
  Dsy Wfm1 mem size
  Dsy Text0 mem size
  Dsy Text1 mem size
  Acq number of digitizers
  Acq mem size
  Cpu timer interval uSec
  Cpu Dram size
  NvRam mem size
  Limit to 1GS/sec presence
  Opt Math Package presence
  Opt Telecom Masks presence
  Opt 3C presence
  Opt 4C presence
  Opt RS232/ Cent presence
  Opt 1M presence
  Opt 2M presence
  Acq Intlv Cal Id presence
  Opt TvTrig presence
  Opt TvTrig index
  Dsy color presence
  Opt floppy drive presence
  Opt hard drive presence
  Acq number of user channels
can't open input 'fd0:/startup.bat'
  errno = 0x13 (S_errno_ENODEV)

Smalltalk/V Sun Version 1.12
Copyright (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: [Select]
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 = 0x67
        IMR 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 Protected

Flashrom 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.
« Last Edit: November 12, 2024, 05:10:45 am by amaschas »
 

Online TERRA Operative

  • Super Contributor
  • ***
  • Posts: 3172
  • Country: jp
  • Voider of warranties
    • Near Far Media Youtube
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #9 on: November 12, 2024, 06:27:29 am »
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.
Where does all this test equipment keep coming from?!?

https://www.youtube.com/NearFarMedia/
 
The following users thanked this post: amaschas

Offline 44kgk1lkf6u

  • Regular Contributor
  • *
  • Posts: 76
  • Country: 00
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #10 on: November 12, 2024, 03:48:19 pm »
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.
 
The following users thanked this post: amaschas

Online TERRA Operative

  • Super Contributor
  • ***
  • Posts: 3172
  • Country: jp
  • Voider of warranties
    • Near Far Media Youtube
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #11 on: November 12, 2024, 04:00:25 pm »
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.
Where does all this test equipment keep coming from?!?

https://www.youtube.com/NearFarMedia/
 
The following users thanked this post: amaschas

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #12 on: November 13, 2024, 05:37:38 am »
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.

2434547-0

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.

2434551-1

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.
« Last Edit: November 13, 2024, 06:16:23 am by amaschas »
 

Offline picburner

  • Frequent Contributor
  • **
  • Posts: 559
  • Country: it
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #13 on: November 13, 2024, 07:44:31 am »
An explanation for the lack of response to the *idn? command could be this (taken from the "C" code of the Tektool utility):

Code: [Select]
#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;
    }
#endif

If your firmware is corrupt you will be warned during boot, there is an integrity check for this.
 
The following users thanked this post: amaschas

Online TERRA Operative

  • Super Contributor
  • ***
  • Posts: 3172
  • Country: jp
  • Voider of warranties
    • Near Far Media Youtube
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #14 on: November 13, 2024, 03:17:51 pm »
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.
Where does all this test equipment keep coming from?!?

https://www.youtube.com/NearFarMedia/
 
The following users thanked this post: amaschas

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #15 on: November 13, 2024, 04:36:16 pm »
An explanation for the lack of response to the *idn? command could be this (taken from the "C" code of the Tektool utility):

Code: [Select]
#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;
    }
#endif

If your firmware is corrupt you will be warned during boot, there is an integrity check for this.

Interesting, 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.
« Last Edit: November 13, 2024, 05:01:24 pm by amaschas »
 

Offline picburner

  • Frequent Contributor
  • **
  • Posts: 559
  • Country: it
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #16 on: November 13, 2024, 05:49:13 pm »
According to this document the latest firmware release for a 754C would be the 5.11
But maybe it depends on the hardware version....
« Last Edit: November 13, 2024, 05:53:56 pm by picburner »
 
The following users thanked this post: amaschas

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #17 on: November 13, 2024, 06:09:38 pm »
According to this document the latest firmware release for a 754C would be the 5.11
But maybe it depends on the hardware version....

Oh that's good to know, I was relying on this page: https://w140.com/tekwiki/wiki/TDS754. Maybe a firmware upgrade is in order?

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.

That would be super useful, thank you! Do you happen to know what version(s) of the firmware you have?
« Last Edit: November 13, 2024, 06:12:36 pm by amaschas »
 

Online TERRA Operative

  • Super Contributor
  • ***
  • Posts: 3172
  • Country: jp
  • Voider of warranties
    • Near Far Media Youtube
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #18 on: November 13, 2024, 10:22:56 pm »
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..)
Where does all this test equipment keep coming from?!?

https://www.youtube.com/NearFarMedia/
 

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #19 on: November 14, 2024, 12:28:22 am »
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..)

I 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.
 

Offline picburner

  • Frequent Contributor
  • **
  • Posts: 559
  • Country: it
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #20 on: November 14, 2024, 06:58:56 am »
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.
 

Online TERRA Operative

  • Super Contributor
  • ***
  • Posts: 3172
  • Country: jp
  • Voider of warranties
    • Near Far Media Youtube
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #21 on: November 14, 2024, 11:36:21 am »
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?
Where does all this test equipment keep coming from?!?

https://www.youtube.com/NearFarMedia/
 

Offline picburner

  • Frequent Contributor
  • **
  • Posts: 559
  • Country: it
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #22 on: November 14, 2024, 07:17:43 pm »
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.
 

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 598
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #23 on: December 03, 2024, 07:13:30 am »
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.
Hello @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 @ragges and german member @madao more than 10 TDS500/700/C/D

In 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 @ragges initial github, see the actual files here 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 1

If you want to dump your EEPROM via GPIB, one method is to run getcaldata with protected switch from here https://github.com/tantratron/tektools/tree/master/getcaldata then notice the source file with GPIB address 1

Code: [Select]
 *  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 mode

FILE *outfile;
int f;
#if 0
unsigned long addr;
// addr = 0x00040000L; /* CAL data base address on TDS5xxB,6xxA,7xxA*/
addr = 262144; /* CAL data base address on TDS5xxB,6xxA,7xxA*/
#endif

    print_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: [Select]

#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? will not work.

Albert
« Last Edit: December 04, 2024, 04:44:45 am by Tantratron »
 
The following users thanked this post: amaschas

Offline Tantratron

  • Frequent Contributor
  • **
  • Posts: 598
  • Country: fr
  • Radio DSP Plasma
    • Tantratron
Re: Tektronix TDS754C not communicating over GPIB in unprotected mode
« Reply #24 on: December 03, 2024, 07:16:40 am »
According to this document the latest firmware release for a 754C would be the 5.11
But maybe it depends on the hardware version....
No the lastest firmware is 5.3 and works fine, in fact above document does state TDS540C,F/W,5.3
 
The following users thanked this post: amaschas


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf