Products > Test Equipment

Tektronix TDS754C not communicating over GPIB in unprotected mode

<< < (5/8) > >>

picburner:
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.

TERRA Operative:
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?

picburner:
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.

Tantratron:

--- Quote from: amaschas 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.

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.

--- End quote ---
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: --- *  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;
    }

--- End code ---

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;
}

--- End code ---

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

Tantratron:

--- Quote from: picburner 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....

--- End quote ---
No the lastest firmware is 5.3 and works fine, in fact above document does state TDS540C,F/W,5.3

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod