Tek CSA7404/TDS7000 repair project (Upgraded memory/CPU)

[colorburst]

I'm not familiar with the actual board or the trigger chips, so can't help you there unfortunately.

However, my opinion is that with the acquisition hardware from a TDS7254, your scope is effectively a mislabeled TDS7254. I'd see about fully converting it to a 7254 instead.

Lower BW models tend to have extraneous filters in the signal path and sometimes skip steps in the factory cal. ASIC grades might be different. It can be a very involved modification with many unknowns.

[calibrationfixture]

Hi,

Contrary to the TDS5000B and Non-B Series and the later DPO, DSA and MSO Series there is, as far as I know, no Memory Erasure and Nonvolatile Parts List for the CSA/TDS7000 Series. Later Documents are labeled Declassification and Security. There is a 077-0524-00 Declassification and Security Document which should list these Parts for the earlier TDS6000 and CSA/TDS7000 Series, but concentrates mainly on the TDS6154C.

Calibrationfixture

[charlyd]

for those who are struggling to get there ACQ in line with the unit model. Here is what to do.
in the corner is a bridge array where selection can be made.
This can be done  by planning a zero Ohm resistor over the right pads.  for selection TDS7404  only a R1069 is "0" ohm (bridged)

for tds7254  R1069 and R1062 need to be bridged. so in my case removing R1062  got my board shownieuws as a TDS7404.  and in that family the units 7104,7254,7404  have the same boards apart from the generation number.

[coromonadalix]

@charlyd

thats for the non B models  right ?

thats the question you asked earlier,  how did you find out 

[charlyd]

hi yes this is for the none B  version.
i found out by compare the board with two other 7404 boards i have laying arround.
and these sort of bridge rows are mostly meant for these adjustments.
After removing R1062  (0 ohm)  reinstalling the board and booting up, the board messaged like 7404 and the option key was pickup straight away.

[charlyd]

and for my trigger chips. they seems to be dead. dropping this message...
even thought all diagnostics test are pass

[coromonadalix]

sad for you  and getting these .....   

In the 7404 i restarted, theses chips dont have any hs on them,  and they seem good for now, no discoloration

all tests passed and all channels where fine with a 3.2Ghz  sig generator


i may re-play in it  ...  since we may buy an sds7000a scope soon, the 7404 was a plan B  loll

still had an crazy idea to put an intel 815 in it ... very very tight fit,  but seems to miss a voltage to start ??

[charlyd]

a Quick advise:  add heatsinks better yesterday,... then tomorrow, i did some measurement with the flir, chips temps are way too high, without heatsinks they will die eventually.
but i type this  message over and over here....

[Ghastly]

Hi I need some help. I own a TDS 7254. Everything was working on Windows 98. I upgraded to Windows 2000 and reinstalled TekScope with the program CSA7154-7404_TDS7154-7254-7404_2.5.3. It didn't work and none of the front panel was working and none of the relays were going off. I decided to do a fresh install of Windows 98 again and I'm getting the same issue with a pop-up "The following files did not self-register or unregister 1. C:\Program Files\Tektronix\TekScope\tekGPIB.ocx Class not registered." I really have no idea why none of this is working. Shutting down the machine and going back into 98, TekScope launches and gives me a very bad error, see photo for details.

[coromonadalix]

1st  did you had  dallas dead battery ?    you need to be sure  the vxwork  boot process is good and well configured,

if not  the scope part will not start,  you need to interface  the 10 pins header  onto a serial port and terminal software

this machine is a pc at first, you need to be sure you have all the drivers installed and no exclamation marks in windows device manager

is it a 7254   or 7254B ?      seems a 7254 non B  with the driver package  you wrote

you can even put Windows ME  or Windows 98 SE    better usb drivers ...

Windows 2k  can be tricky on certain motherboards,  you may get into a boot loop

What is the motherboard you have in it ?

i can post  the touch panel driver, power pc driver and other things,  but you need to do some checks first

you can register for free at xdev's   and get some missing drivers   they have a tds7000 and tds7000B  repo

[Ghastly]

Honestly, I just got this a week ago as an upgrade from the 1054z. By dallas dead battery do you mean the coin battery on the NLX board? I can check the vxwork boot process but it would seem weird to me for it not to work. It worked right until I switched and I have no errors when booting into Win98. The only drivers I know and install are the  CSA7154-7404_TDS7154-7254-7404_2.5.3, and yes it is a 7254 not a 7254B. Motherboard unsure, again haven't opened it since it's only been a week since I've had it but my configuration is a Celeron 566mhz with 256mb of ram installed. Am I missing a driver? I can give you the exact installation program I am using. Thanks for the reply though! This is some quite tricky stuff.

[Ghastly]

Side note: I remembered I did actually save some of the folders just in case prior to upgrading if that makes any difference. Details in pic.

[coromonadalix]

if you backed theses folder, you have the folders who contain the needed drivers

for the gpib interface you need the drivers setup

for the dallas battery  it is on the power pc board under the computer motherboard  dallas  ds xxxxx   


well since its a used scope you've bought,  do you have an idea of it's history / checkups / maintenance ??     dust cleaned ??  a checkup  has to be made

if windows boot fine minus some errors,  you have to check device manager

you can kill the scope software if  with a keyboard    crtl alt del  you invoke task manager and kill the tekscope running task


i have a 7404 non B,    who seemed fine  and the next day,  hell happened, took me 2 weeks to re-install everything  and find appropriate hardware to do re-installations, win2k was not working, endless loop,  ended up with Windows ME, with all the crap removed

motherboard (su 810) is hardware locked, you can not connect all you want, or all you need ...  hard drive size too   etc ... the cd-rom  would not read burned cd's,  finding originals was tough, changed to a 1ghz cpu, and doubled the ram with a mix of pc133 sync and pc100 sync (would not accept the same sizes and speed ?)

you have to read the tds7k thread,  its huge but the last pages have more recent informations ... 

the power pc dallas battery died, lost the vxwork configs ... tekscope was hanging up and crashed, spc errors due to eeprom corruption  ...

now fully working, spc fine etc ...

its a big beast you bought,  with some quirks     you should not have tampered with it,  unitil you had done an hdd cloning

[Ghastly]

Thank you. Ill check out the stuff you told me tomorrow not at the bench now. Last calibration date I think was 2015 that's traceable. And yes you are absolutely correct. Really should have cloned the drive.

[hazelnutsky]

Hi,

This thread is AMAZING! I recently got me a TDS7404, with some issues.

I am using these two sites for reference:

https://www.eevblog.com/forum/testgear/tek-csa7404-repair-project/850/
https://github.com/exit-failure/tds7000/blob/main/NVRAM/README.md

I have managed to fit a new NVRAM battery onto the PPC board, and have figured out how to connect up and capture the PPC console port output. I have also done the modification of the c:/vxBoot/topscript.hw to reset the NVRAM.

    # remove '#' from next line to set powerup scope state to factory default:
    NvramClearDb = 1   




So I am a little confused why I don't get the countdown in the console chatter, it just goes right to 0.

    Press any key to stop auto-boot...
     0
    auto-booting...

I tried a few things on the Console port, such as RTS-CTS loop back and DSR-DTR loopback but still it does the same. I am using puTTY on a windows 10 machine with a native RS232 port.

Here is my console chatter during a SPC:

    0x15f8570 (SPC task): cc_loadV: CC_TRIGdcGain1c was 0; clipped
    0x15f8570 (SPC task): cc_loadV: CC_TRIGdcGain1d was 0; clipped
    0x15f8570 (SPC task): cc_loadV: CC_TRIGdcGain2c was 0; clipped
    0x15f8570 (SPC task): cc_loadV: CC_TRIGdcGain2d was 0; clipped


Here is my console chatter during a Diagnostic:

    DIAGNOSTIC EXECUTION begin
    OptionST not tested. (option not enabled)
    BK2 not tested (option not enabled)
   
    DIAGNOSTIC EXECUTION finished

My conclusion here is my Ch1/Ch2 Trigger chip is fried. CH1 does not edge trigger, but it does trigger on level in Advanced settings. Does this seem correct?

[hazelnutsky]

I am unable to change my bootflags. I discovered that if I hold down the 'p' key in puTTY while the TDS7404 is powering up, I can get into the boot menu.

    Press any key to stop auto-boot...
    p1
    [VxWorks Boot]:

I would expect at this point to be able to change to bootflags from 0x1008 to 0x1000 which should enable the boot countown.

    [VxWorks Boot]: c
   
    '.' = clear field;  '-' = go to previous field;  ^D = quit
   
    boot device          : sm
    processor number     : 0
    host name            :
    file name            : c:/vxboot/vxWorks.st
    inet on ethernet (e) :
    inet on backplane (b): 192.168.0.1:ffffff00
    host inet (h)        : 192.168.0.2
    gateway inet (g)     : 192.168.0.1
    user (u)             :
    ftp password (pw) (blank = use rsh):
    flags (f)            : 0x1008 0x1000
    target name (tn)     : tds7000
    startup script (s)   : c:/vxboot/topscript.hw
    other (o)            :
   
    [VxWorks Boot]:
    [VxWorks Boot]: p
   
    boot device          : sm
    processor number     : 0
    file name            : c:/vxboot/vxWorks.st
    inet on backplane (b): 192.168.0.1:ffffff00
    host inet (h)        : 192.168.0.2
    gateway inet (g)     : 192.168.0.1
    flags (f)            : 0x1000
    target name (tn)     : tds7000
    startup script (s)   : c:/vxboot/topscript.hw

    [VxWorks Boot]: @

    boot device          : sm
    processor number     : 0
    file name            : c:/vxboot/vxWorks.st
    inet on backplane (b): 192.168.0.1:ffffff00
    host inet (h)        : 192.168.0.2
    gateway inet (g)     : 192.168.0.1
    flags (f)            : 0x1000
    target name (tn)     : tds7000
    startup script (s)   : c:/vxboot/topscript.hw

As you can see, after the @ command is issued, it appears the flags are 0x1000, but if I wait for the scope to fully boot up into the scope screen, and then power cycle the boot flags have reverted to 0x1008, and there is no countdown . grrr. Comparing the console chatter while the topscript is running with the exemplars provided in this thread, I find I have this extra bit:

      nvram_initFileSys
    0x16987e0 (tShell): >> Kernel version 1.0.8.0  does not match Boot ROM version 1.0.4.0
    value = 21801184 = 0x14ca8e0

Where the Exemplar has the following (spelling of "existing" is correct):

      nvram_initFileSys
    0x1d987e0 (tShell): >> Restoring exisiting filesystem in NVRAM...
    value = 29213952 = 0x1bdc500

 

[coromonadalix]

damn cant recall what to do ..    there was a way to correct the kernel version to match  ...


not sure if you have to edit the topscript and clear the nvram

see this thread

https://www.eevblog.com/forum/repair/boot-problem-on-tektronix-tds7404-scope/

and the script collection   ------  attached

[hazelnutsky]

Cool, I followed the thread! I found I had a boot.bin AND topScript.vxw in my vxBoot folder, and sure enough my Hex editor showed the 1.0.8.0 signature, so I temporarily renamed my vxBoot/topscript.hw and ran the following commands:

Code: [Select]

-> pwd
dbfs:
value = 6 = 0x6
-> cd "c:"
value = 0 = 0x0
-> pwd
dbfs:c:
value = 8 = 0x8
-> cd "vxboot"
value = 0 = 0x0
-> pwd
dbfs:c:/vxboot
value = 15 = 0xf
-> < topScript.vxw
    #################### topScript starts ###############################
    #
    #  This script is for standalone prototypes that want to update
    #   their bootROMs to the newest version in the
    #   scope's c:/vxBoot directory.

    sysFlashUpdate ("dbfs:c:/vxBoot/boot.bin")
sysFlashUpdate: TESTING: comparing region
sysFlashUpdate: Erasing flash...done
sysFlashUpdate: Writing flash sectors
s0@0xff800000................
s1@0xff810000................
s2@0xff820000................
s3@0xff830000................
s4@0xff840000................
s5@0xff850000................
s6@0xff860000................
s7@0xff870000................
sysFlashUpdate: SUCCESS: flash written
sysFlashUpdate: TESTING: comparing region
value = 0 = 0x0
    setLED 0x40
value = -65 = 0xffffffbf = ppp_parms + 0xffc4f02f
    #
    # hopefully you get this message at the end:
    # sysFlashUpdate: SUCCESS: flash written
    # sysFlashUpdate: TESTING: comparing region
    # value = 0 = 0x0
"

A power cycle later and the bootup is now showing 1.0.8.0 :

Code: [Select]


                            VxWorks System Boot


Copyright 1984-1996  Wind River Systems, Inc.





CPU: Tektronix HPP - PowerPC 740
Version: 5.3.1
BSP version: 1.0.8.0
Creation date: Jun 27 2003, 09:52:32




Press any key to stop auto-boot...
 0
auto-booting...

Next I renamed the topscript.hw file, and restarted the scope again, and now the pesky mismatch error has gone!

Code: [Select]

    # remove '#' from next line to set powerup scope state to factory default:
    # NvramClearDb = 1

    nvram_initFileSys
value = 21801184 = 0x14ca8e0


I sort of knew this wasn't going to fix my edge trigger issues, but I had to try and do another Cal, but of course console says "no"

Code: [Select]

-> 0x15f9170 (SPC task): cc_loadV: CC_TRIGdcGain1c was 0; clipped
0x15f9170 (SPC task): cc_loadV: CC_TRIGdcGain1d was 0; clipped
0x15f9170 (SPC task): cc_loadV: CC_TRIGdcGain2c was 0; clipped
0x15f9170 (SPC task): cc_loadV: CC_TRIGdcGain2d was 0; clipped

Also the edge trigger on Ch1 and Ch2 still doesn't work. Plus I still cannot change the boot flags to 0x1000 !! Arggh.
Next step is remove the commented out line from topscript.hw, to clear the NVRAM again. Reboot, and try to set bootflags = 0x1000, but no, it just reverts to 0x1008 . Why ?

[hazelnutsky]

Today I have these issues:

• I have calCons errors.
• The RTC is not running when the scope is switched off.
• CH1/2 edge trigger are not working.
• Signal Path Calibration Fails.

For the calCons errors I was seeing this:

Code: [Select]

    calConStatus = cc_init(2)
0x16987e0 (tShell): Reading 300 bytes of service cal data from EEPROM[0] into 0x3719220
0x16987e0 (tShell): nvMem_read succeeded
0x16987e0 (tShell): Reading 82 bytes of service cal data from EEPROM[300] into 0x3719300
0x16987e0 (tShell): nvMem_read succeeded
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/0
0x16987e0 (tShell): cc_init: bank 0 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/1
0x16987e0 (tShell): cc_init: bank 1 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/2
0x16987e0 (tShell): cc_init: bank 2 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/3
0x16987e0 (tShell): cc_init: bank 3 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/5
0x16987e0 (tShell): cc_init: bank 5 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/6
0x16987e0 (tShell): cc_init: bank 6 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/7
0x16987e0 (tShell): cc_init: bank 7 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/8
0x16987e0 (tShell): cc_init: bank 8 chksum failed, NOT reset to factory
0x16987e0 (tShell): cc_restoreBank: can't open file C:/vxBoot/calCons/15
0x16987e0 (tShell): cc_init: bank 15 chksum failed, NOT reset to factory
0x16987e0 (tShell): Optical hardware is not present.
calConStatus = 0x1335528: value = 33263 = 0x81ef

But I copied in the missing files from the attachements on this message:

https://www.eevblog.com/forum/testgear/tek-csa7404-repair-project/msg4300990/#msg4300990

And now I get this:

Code: [Select]

    calConStatus = cc_init(2)
0x16987e0 (tShell): Reading 300 bytes of service cal data from EEPROM[0] into 0x3719220
0x16987e0 (tShell): nvMem_read succeeded
0x16987e0 (tShell): Reading 82 bytes of service cal data from EEPROM[300] into 0x3719300
0x16987e0 (tShell): nvMem_read succeeded
0x16987e0 (tShell): Optical hardware is not present.
calConStatus = 0x1335528: value = 0 = 0x0

Also I note the levels of the probe compensation are much closer to the 1.0V and 0.8 values on all channels, like really close now 1 or 2%. So that is a win.

The CMOS battery (CR2032 on the intel PCB) was replaced yesterday, and the time set in the BIOS. The scope was switched off overnight, and today when powered up it was still saying the time I entered into the CMOS last night. D'oh.

The NVRAM battery replacement is working a bit better, as the instrument configuration was correctly recalled, so I will celebrate that small win.

I am fairly certain now I need a trigger IC.

[hazelnutsky]

In the BIOS, the RTC is not changing, when windows shuts down it seems to update the RTC with the advanced time, but all the time the scope is turned off, the RTC does not count.  Can someone please confirm their RTC counts while in the BIOS settings ?

[coromonadalix]

the motherboard rtc  is running ok on my 7404,  the battery on the modo  is the rtc and bios settings,
this one dies, you normally loose  some configs for the lcd and need to put back the right ones

the dallas battery  on power pc  is for information storage  .. if this one dies, you need to reconfigure the power pc VxWorks boot infos


they are not related

@hazelnutsky     

in the windows once tekscope is started, i kill tekscope thru crtl alt del  to invoke task manager,  i use windows to change clock settings, and they are wrote on the motherboard  ?? time zone etc ... ?? (i have the SU810 board tds 7404)

do read about  eeprom corruption in  u1250 if i recall,   mine was corrupted and gave false SPC errors  ....

the calcons  file can be replaced, for sure you need to redo a full spc  and maybe   a scope calibration ??

if the rtc does not run well, maybe you have pc motherboard problems    
 
in my case i put an original intel bios in it,  to access the mobo configs,  not the TEK  branded / crippled one,  and i dont care if i dont see the TEK logo while booting  loll

and for the trigger chips, you know they are unobtanium ...  you need to find  acq board for 6 or 7 k series

[hazelnutsky]

Well, The 32KHz was not present on the NLX crystal. It had something like 60khz at a very low amplitude. I removed the crystal, and put into a handy kitchen timer, and the crystal is fine. So motherboard is dodgy. Replaced the crystal, and now the Scope will not power up.

I've started the diagnostic procedure in the service manual. Fuses and leads OK, have red LED in middle of PSU. Pressing front panel power has no effect. I tried shorting the PPC "Debug power-on" and the PSU seems to spring into life. I guess I turned it off and on one too many times...

UPDATE.
The crystal runs to an Intel 82801 ASIC. This chip contains not only the RTC but the power control circuitry, so if the crystal is removed, the scope will no longer power up.  I've put the crystal on a little 0.1" jumper, and when connected, scope powers up, but when removed it does not. Interestingly if an external 32kHz signal is applied, it will then start up, but again my RTC is still stalled.

[hazelnutsky]

Help!

I'm wanting to replace my faulty NLX board (A Radisys SF810).

I'd like to buy a cheaper SF810 board and re-flash it, but I cannot find the UniFlash software (uf140.zip) or the BIOS dump (CSA7404.BIN).

My information sources so far are these (and of course this superb thread)

https://github.com/exit-failure/tds7000/blob/main/README.md
https://xdevs.com/fix/csa7404/
https://www.rainbow-software.org/uniflash/

Did anyone happen to have these laying about? (I have the Radisys SF810 Manual).

-H

UPDATE:

I figured out I could get the Uniflash files using the Internat Archive, and going back to 2015 :

https://web.archive.org/web/20151007044113/https://www.rainbow-software.org/uniflash/

Then I found another link at the bottom of the page (References item 3) to get the BIOS binary.