Major Boot failure TDS784D

[Tantratron]

I've purchased recently a TDS784D on eBay which was clearly stated as failed so i could get parts for my other TDSxxx serie C/D. It turned out first the PSU was not working plus it is a very old model (TDSxxx no suffix or maybe serie A). For sure the PSU has not exactly the same circuit as most PSU's i've seen on serie C and serie D. Anyway since I had a spare PSU then I've replaced to investigate more how to repair the TDS784D. It turns out the CRT and its electronic board are OK, same for the Front Panel and the Acquisition board BUT I'm faced with a hard situation regarding the A11 main board.

The symptom is really simple and nightmare, during the power ON then boot, in no time the 7 segments LED display shows .E failure. It seems no schematics or component manuel exist for C or D serie which does not help so i've looked on TDS520D component manual to guess a bit the situation.

Obviously the .E failure at boot or self-test means an Exception from the 68040 or 68020 processor.

When connecting the Console port on J40 there will be no message, the Serial Debug Port is not initialized.

Same when connecting a GPIB-USB again no response so the GPIB controller is not initialized.

After that I've tried different 8 bit DIP switches inspired from the TDS520B repair document with hypothesis it works for D serie:

• 1X00 0001 will display 1 so Bus Control read is OK
• 1X00 0010 will display 2 so Kernel RAM Test 1 is OK
• 1X00 0011 will display 3 so Kernel RAM Test 2 is OK
• 1X00 0100 will display 4 so Kernel RAM Test 3 is OK
• 1X00 0101 will display .E instead of 5 so BootROM Check Sum Test is KO or failed

Most other 8 bit DIP combination will show .E failure except the 01X10 0010 (Walk 7 segment LED) and 1X10 0011 (Display Processor Version Number).

Has any of you have seen similar boot failure where again the challenge here being that the boot fails so fast so we're blind, no J40 Console port neither GPIB access are activated.

Thank you for any help or suggestion, Albert

[Tantratron]

Since we do not have schematics of TDSxxx serie C or D then i've patiently observed the known schematics of TDSxxx serie B where many chips are the same, the numbering of the chips stay the same. Of course there new chips, new circuits but it seems the Kernel part of B serie or D serie is roughly the same.

So I did find U1331 chip with host the BootROM, the U840 Kernel RAM, the U1082 and new chip called U16 acting as an octal transceiver. After DMM testing the connections, the 1st difference between A-B serie and C-D serie lies on the control lines of CE (Chip Enable) and OE (Output Enable). The 2nd difference being that U1331 is connected to U16, the later connected to Kernel bus (KA and KD) whereas tektronix kept U840 always connected to the Kernel Bus.

Make a note J40 does keep the principle to have the upper most 8 bits of the kernel data bus and the lower most 5 bits of kernel address bus.

The first picture shows where I did soldered pins to ease the installation of my three P6243 probes and I'm leaving the 4th probe to check any data bus line:
* the green probe reads U840-CE pin
* the blue probe reads U1331-CE pin
* the red probe reads U1331-OE or U840-OE where both signals are shared on J23-3 test pin connector

I'm using my good TDS794D (option 1M and 2C) with Single Acquisition Sequence mode, memory length set to 50,000, sampling 100MS/s which can be zoomed and the triggering on BootROM Chip Enable fall. This way I can really see what happens when the TDS boots then zoom since I do not have a Logic Analyzer.

As a reminder, my TDS784D fails to completely boot at 5th test where in the following pictures, you see test 1 then test 2 up to test 5. The choice of these test are controlled by the 8bits DIP switch and the result on the 7segments LED display.

The test1 shows the kernel ROM being read and the kernel RAM not active (check Green stays HIGH). The loading of the ROM seems to last around 96 us.

The test2 again only ROM is active but its reading by 68040 or other processor (U2000 or U2001) shows now more bits circa 120 us.

The test3 fir the first time shows both kernel ROM active and kernel RAM active, the duration of ROM reading is now circa 128 us.

Test4 now only goes to kernel ROM active, this time 130 us.

Finally test5 shows again both ROM and RAM active circa 126 us, this is when an Exception is raised by the processor.

You have then two more pictures where the yellow trace shows (no zoom) then zoom at start the content of ROM-bit0.

N.B. Check all pictures on next post

Roughly we can see that the KD (Kernel Data bus) is clocked circa 2.5 MHz

The million $ question, what method could I use to actually store and then read the BootROM content to check it is same as the ones dumped via GPIB-USB on a healthy TDSxxx. My big problem here, the fails prevents the initialization of the Console Port and the GPIB port so I need to use my healthy TDS794D to Single Seq acquire the 8 bits of Kernel Data bus.

Otherwise I could go after a new ROM chip programmed with C-D boot rom firmware but this is 32-PLCC, my soldering skills are low so I really want to be sure the problem.

Anyway maybe you have other ideas to ease this investigation where at least now we have some ideas of how the Boot runs, obviously dumping blocks bigger and bigger.

When using my GPIB-USB and tekfwtool on a healthy TDS540C and TDS794D, both shows the same file content, namely 1st boot block of 29472 bytes followed by a 2nd boot block much longer. The global ROM is higher than 201760 bytes. Removing the white sticker (firmware) from U1331 reveals to a 27C040 EPROM (OTP - One Time Programmable) which is 512Ko memory.

Voila, Albert

[Tantratron]

Following previous post, thank you.

[Tantratron]

Some further probing when test1 test2 test3 test4 and test5, now the YELLOW trace is U840-27 (Write Enable of kernel RAM) in the attached pictures.

We clearly see progressive writing from ROM to RAM within Kernel Bus...

[Tantratron]

On an additional note and test, few days ago I did install both NVRAMs from the failed TDS784D main board into my working TDS540C which runs with 5.2e firmware. All the self-tests are OK then the complete boot is done where my TDS540C works fine with these NVRAMs. This proves one thing, the NVRAMs are not corrupted or out of battery, they're OK so whatever hard fails the boot of my TDS784D is really of another root cause profile.

What really helps and bring speed testing, my 5 main TDSxxx boards (two mono and three color display) are now with NVRAMs 32 pins sockets so I can swap NVRAMs, dump or write them via my GPIB-USB with tekfwtool.

By the way, when you boot any TDSxxx serie C or D without the NVRAMs, it will stop with flashing .b on the 7 segments display confirming the TDS520D Component Manual. The DOT or . before the letter indicates a failure whereas the same letter without dot means that test is success

[Tantratron]

As mentioned, no Logic Analyzer for the moment so I've decided to trigger and decode visually the first 24 bit data which are from from the BootROM. Attached pictures of each Dx bit (x=0..7) then Big Endian decoding to compare if they match with a valid copy of the BootROM (TDSxxx serie C or serie D).

Green trace is U1331-CE
Blue trace is U1331-OE
Red trace is U1331-Dx (bit x from output bus)

First observation, the first 8 octets coming from my failed TDS784D are the same as valid known BootROM read from its address 0

Second observation, it seems the kernel operating system will then read from address 8056 in the BootROM. The 16 octets read from the failed TDS7894D still match the valid BootROM content.

Of course, maybe there could be few bit rot (corrupted bit) in my BootROM so only Logic Analyzer would help ease the effort since the BootROM is quite big.

However I'll try later to check what is written on the KernelRAM during boot test 5 because we cannot exclude possibility of kernel SRAM to have an issue.

The way I understand the kernel OS, it first read a part of BootROM, does test 1 then test 2 test 3 test 4 and during test 5, it will copy part of the BootROM in the KernelRAM to then self-test the check sum of the BootROM. I still have no idea what processor or controller does execute the firmware stored in the KernelRAM (68040 or U2000).

[Tantratron]

If it can help anybody in the future, I'm attaching my own sketch which reverse engineers the local schematics, signals of logic board (Serie C and serie D) involving both the BootROM (U1331) and KernelRAM (U840) with the signal controls (CE Chip Enable, OE Output Enable, WR Write Enable...).

Do make a note that roughly it is the same as the TDS520B so I assume Serie B except one key detail or difference. Namely the U1331 has a Transceiver (U16) to connect on KD (Kernel Data Bus) wth C-D serie whereas on B serie and probably A serie, the U1331 is directly wired hot live onto KD along KernelRAM along with other peripherals sharing the KD and KA (Kernel Address).

As a reminder, the Kernel Space (KA and KD) seems shared with DATA BUFFERS, ADDRESS BUFFERS, KERNEL RAM, BOOT ROM, 7 SEGMENT LED, GPIB, GPIB (J35), SERVICE PORT (J40) and 68020 INTERFACE (Kernel Registers Decode, ID register, DRAM logic, DSACK logic, BYTE enable decode and DIP SWITCH).

It seems the good news is that C-D serie A11 processor board regarding the Kernel Space seems more or less the very same as B serie.

To go back on the DIP switch commands (test 1, test 2, test 3.... up to test e), my A11 logic board boot failure occurs at test 5. All previous test are healthy so I've re-done same test 1 to 5 with my valid TDS540C. Good to know that upon test 1 to test 4, in fact the Console Port will be not initialize hence no Console Port activity from J40. However with heathy TDS540C at test 5, the Console Port will now work and report the BootROM to be check sum valid then loop on this BootROM test.

This is the explanation where my failed TDS784D at test 5, no Console Port because for whatever reasons, the test fails hence no console port as a mean to investigate.

Only choice being that I continue to use my 4 tektronix probes and my other valid TDS784C to check or record as a Logic Analyzer. My idea is to compare both signals from U1331 and U840 between a valid TDSxxx-C and my failed TDSxxx-D.

It is quite heavy work load but at least, I do have 2 valid TDS oscilloscope, one to displays and record logic signals, another one used as healthy working reference for those signals and the last one being the boot failed (see attachement).

Albert

[Tantratron]

Hello and special thanks to private help from @madao @strick and @charlyd

Here is a status after trying different probings strategies, recording with deep memory (option 2M option of my TDS784D), observing signals of good TDSxxx versus bad TDSxxx to find out a pattern to be investigated.

The way I now use the 3rd TDSxxxD to record and display the bus lines:
* the J23-1 test pin (KAS Kernel Address Probe) goes into AUX input with P6139A passive probe with fall triggering
* the green trace is SRAM Chip Enable
* the blue trace is the EPROM Chip Enable
* the red trace is the SRAM Write Enable (J23-4)
* the yellow trace is J40-A4 connector corresponding to KRNW signal

As a rule of thumb, we can consider in most cases that SRAM Chip Enable is followed by SRAM Output Enable or Write Enable whereas the EPROM Chip Enable is followed by Output Enable. The 8 bits parallel which are sub-part of the 32 bits parallel are easy found on J40 connector.

What is really important to see in the attached 8 pictures, during test 5 phase of the boot when forced to loop via the DIP switches choice, the KRNW (yellow trace) goes pattern cyclic. With the healthy TDS the complete loop to re-run test 1 to test 5 is near 400ms but with the failed TDS, it is around 125 ms. Furthermore we see on the pictures that from 90ms the waveform are really different: good boot and partial failed boot.

Luckily I do have 2M options with my 3rd TDS but it will record half of the time after the trigger. Practically after trigger event, I'll get in fact 4 Meg recording (1 channel), 4 meg recording (2 channels)... even though total memory is 8 Meg.

My idea now of hacking and spying the 8bits parallel bus would be to record say 200 ms of bus activity to embrace the failure near 90 ms time after boot initialization. This would be done on both TDSxxx (good and bad) to then compare the bit streaming different of EPROM and the SRAM.

This could be done in theory by recording each bit, reboot then each time save via GPIB and Python-Visa which works good on my MacBook Air then re-build the actual HEX content of the 8bits parallel.

Another option would be that I purchase a USB logic analyzer made by SALEAE (Logic Pro16), it has much bigger deep memory plus streaming bandwidth. This way i'd get at the same time the chip signals (Enable, read, write) and the 8 bits parallel except I'd need to write a special C routine to implement the asynchronous parallel bus decoder not found on SALEAE suite.

Note that the asynchronous clock of the TDSxxx Kernel bus is around 2.5MHz so I need to have at least samples per clock and ideally say 10 samples per clock to properly decode the bits. All this to say that now it is clear the boot failure occurs between 125 ms to 500 ms but the TDS784D even with 2M options does not have enough deep memory recording.

Either I'll go hack the hard and pain way with no budget or I might decide to purchase SALEAE or another USB logic analyzer... not easy with Covid19 economical impact but at least, thanks to three TDSxxxD now I can identity where and when to look for the boot failure.

P.S. Most of the built-in decoders of SALEAE are serial so not applicable here but I might use the unit to try some RF hacking projects. After all, a wireless bus is serial

[Tantratron]

Very bad and sad news… here is an update with special thanks to @cuebus

I’ve finally managed to remove the EPROM memory using ChipQuik method. Then I’ve cleaned the pads using some braids, flux and visual inspection seems to show no issue on local PCB traces. After that I've re-soldered each pin of the new EPROM (check attached picture) but the boot failure persists, it really sucks... the new EPROM has been programmed with a valid boot firmware

I believe unless wrong that the content of the new EPROM to be correct as well as my soldering the 32 pins of the new EPROM because the boot test will pass again phase 0, phase 1, phase 2, phase 3, phase 4 but will fail the phase 5 showing again the .E exception on the 7 segments display.

So either I'll have to acquire a logic analyzer (i.e. SALEAE) but what is clear now, the BootROM checksum is declared invalid cannot be rooted in the actual BootROM content (chip U1331 - 27C040).

[Tantratron]

The bad news continue because few days ago, I decided to change the Kernel SRAM (U840) but still boot failure at test 5.

Test 5 says bad Boot ROM check sum from the start, I've changed the ROM (U1331) by a new one with valid boot firmware, now I've changed the SRAM but still 68040 will raise an Exception hence boot failure.

[Tantratron]

Hello, it has been a significant time with no news on this failure so I kind of gave up.

I did initiate similar thread on tek forum with some extra testing back in 2021, you might read this thread https://forum.tek.com/viewtopic.php?f=568&t=142561 but at the end, I gave up as well 2 years ago.

However one year after, another member @racusa from Spain reported the same failure on his TDS754D, see this thread on tek forum https://forum.tek.com/viewtopic.php?f=568&t=143110 then he read my thread.

To make long a short story, I decided to start again with racusa (Jorge) probing and partially reverse engineering the processor board where the difficult is not tektronix schematics manual is available for C and D serie. I need to thank racusa (Jorge) on the other forum, we both patiently used logic analyzer (16 channels), comparing our reads of BootROM.

I'm attaching a sketch showing my reverse engineering (simplified) where the big difference with C/D series being the DRAM are outside the Kernel but the U1 chip translator of both 68020 and 68040 world plays huge role.

Initially we thought the problem was the BootROM because racusa content was not the same but later I discover two firmware exists for BootROM depending on DRAM technology (5V or 3.3V). In the attached document which I wrote end 2022, you'll see the different firmware and chip names so it really depends if processor board is early C/D or late C/D. When I was comparing the content of BootROM (U1331) from a valid TDS540C, another valid TDS794D made me realize the firmware difference 163-1112-00 and 163-0692-00. Depending the BootROM firmware, a specific firmware for U1 translator chip, namely 163-1113-01 versus 163-0790-00. Then we knew my failed TDS784D BootRom as well the failed TDS754D of Jorge werz in fact valid even though kernel test said no.

Anyway after many hours, many weeks, many months, a fantastic spanish-french cooperation... well we found the problem was faulty DRAM.

Part of the problem when Kernel booting, the code is copied and executied outside the Kernel inside the DRAM. In the A/B serie all were together in Kernel but the evolution from 68020 to 6840 while keeping most of the same expensive acquisition board under 68020 commands. The kernel boot does not check anything outside the Kernel hence we just have a code exception which is true but not due to BootROM...

Unfortunately tek forum stopped being in activy almost one year, time passes by then I thought to report the repair of this bootfailure in our forum here.

Hoping this update could help someone in the future, if needed more schematics and pins out could be generated.

Not sure if racusa is a member here but I'll inform in private to add more information if he likes to.

Albert