TDS3052 stuck at splash screen

[meduza]

Hello, and good day for everyone. My TDS3052 stuck at splash screen. Front panel LED's blinks shortly, floppy drives moves for a moment, and nothing happens then. I tried holding "B TRIG" during powering on, but it doesn't change anything.

Prehistory:
1. I bought TDS3052 (no suffix), it worked fine except date/time and settings aren't saved, and the floppy drive failed to read disks ("mass storage error").
2. I desoldered Dallas' DS1742W-120, and with surgery removed old battery and soldered a new one, installed the chip back with a socket.
3. I removed floppy drive, cleaned heads, and lubricated.
4. Assembled, and now I have the problem described above. I tried removing the Dallas chip, or just the battery, or the floppy drive, it doesn't help.

Does TDS3000 scopes boots if Dallas chip is not working or have wrong data in it? Maybe anybody can check that by removing the chip (if it's installed in socket), I will be thankful very much.

[benj38]

Is the screen solidly stuck on the splash screen, or does it periodically flicker to momentarily show a blank white screen?

[meduza]

It continuously shows the splash screen. I also checked the voltages +5, +15, -5, -15 on the TekProbe pins: they are ok.

[benj38]

It is not very common, but I have seen my share of DS1742W chips where not only the battery is dead but the SRAM chip inside is dead as well. Depending on its mode of failure, I have also seen it prevent the scope from booting.

Given that you have performed surgery on the chip, and that the scope booted fine before the surgery, there is a good chance the chip died during the operation. I assume you verified that you installed the socket and the chip in the socket correctly.

Wrong data in the chip will almost never prevent it from booting, but who knows if some exotic combination of bits confuses the software enough?

If you have a programmer (like a TL866), it is not too hard to test if the chip is working or not by trying to program the time, and seeing if it accepts your programming, and that the time advances correctly. I have not seen a chip that passes this test that is bad.
You can figure how to do it by reading the datasheet. However, if you need help I can try tomorrow to provide some information to guide you.

You can also use the programmer to program the chip to a nice stable starting point that would guarantee success if there is nothing else wrong with the scope.

[picburner]

The DS1742W runs at 3.3V (it doesn't have to be powered by 5VDC!) and many budget programmers don't even consider it.
In addition to being a sram it is also a timekeeper: the last bytes mapped in memory are reserved for the internal clock.
A unhappy combination of random data that ended up inside the sram during battery replacement could cause the scope not to start.
In this forum, somewhere, if I remember correctly there is the procedure to follow to restore the data contained in the sram, data of course to be customized with your serial number, MAC Address etc. etc.

[benj38]

The DS1742W is indeed a 3.3V chip (that is what the "W" in the name indicates). However, the datasheet clearly states that it is 5V tolerant, and many people have successfully programmed it with 5V.

Most budget programmers do not have it in their list of devices, but you can chose an SRAM chip close enough (without timekeeping abilities) to program and test it. I do not remember of hand a 5V chip the TL866 supports that you can chose, but it should not be hard to find by reading pinouts in a few datasheets.

If you want to play by the book, the TL866 supports the DS1230W SRAM chip, which is also a 3.3V unit (no timekeeping). It is a 32Kb unit, whereas the DS1742W is a 2Kbyte unit, so you can not plug it in directly to the TL866. Instead, plug it into a small breadboard, and use jumper cables from the breadboard to the TL866 ZIF socket as follows:

Pins 1 to 12 of the DS1742W go to pins 3 to 14 of the TL866, pins 13 to 20 go to 15 to 22 of the TL866, pin 21 goes to 27, 22 and 23 go to 24 and 25, and 24 goes to 28. Note that pins 1,2,23,26 of the TL866 are not used (these correspond to 4 address lines that the DS1230W has that the DS1742W does not).

Since the TL866 does not power the chip between programming and reading it may not be a bad idea, especially when playing with a chip that has an empty battery, to have a 3.3V external supply connected between pins 12 (GND) and 24 (+3.3V) of the DS1742W. If you do so, disconnect pin 28 of the TL866 from pin 24 of the DS1742W.

Make sure you set the programmer's address range to 00000000 to 000007FF. Do not leave it at the full 32Kb range up to 00007FFF!

Finally, there is nothing critical stored on the chip that does not get replaced automatically at startup by the scope. In particular, there is nothing specific to the individual scope (like a serial number) except for the number of minutes it was powered up (which really is not important) and, on "B" series scopes, the MAC address. On plain series scopes, like that of the OP, Ethernet is optional and the MAC is stored on the Ethernet plug-in option module instead. You really do not have to customize the programming of the chip to your specific unit, and in fact you can leave it zeroed out.

However, if you have to program it anyway, why zero it if you can do it right?
You can use a dump of any chip in the plain TDS3000 family to put on your chip and everything will function correctly. A search on this forum should easily yield such a BIN file. For a "B" series scope, if you leave things zeroed the Ethernet will not work. In this case you can simply use any dump of another "B" series scope to program your chip, and your scope will have the same MAC address as that other scope. Who cares. If you really want to, you can edit the MAC address: it is in offsets 0x06F0 - 0x06F5. If you do, make sure it starts with the Tektronix assigned range of 08:00:11, otherwise the Ethernet will not work.

[sicco]

Does TDS3000 scopes boots if Dallas chip is not working or have wrong data in it? Maybe anybody can check that by removing the chip (if it's installed in socket), I will be thankful very much.

Maybe yes, maybe no. The DS1742W will reset to ex-factory condition when the power supply has been <<1V. When connecting a new battery, it stays in a dormant mode where the RTC clock does not yet run. This so that shelf battery life of the DS1742W is longer.



There's also a test mode that might bite if it gets enabled...

The OSC bit at the wrong level stops the 32 kHz oscillator, the RTC then does not tick, and that may also prevent decent TDS3000 booting.

Expect random values in these /OSC, FT and X bits after reconnecting a battery that was (very) empty. That why it's maybe yes, maybe no.

Overwriting the full 2kbytes in a TL866-ish eprom programmer may or may not rectify this stumbling block: see the W and R bits definition in the century register...

Failing everything, consider using the FT4232H based USB-BDM interface and second-life-board plus PC code. That enables loading these registers properly, without taking out the DS1742W from the TDS3000 board.

[benj38]

Overwriting the full 2kbytes in a TL866-ish eprom programmer may or may not rectify this stumbling block: see the W and R bits definition in the century register...


Failing everything, consider using the FT4232H based USB-BDM interface and second-life-board plus PC code. That enables loading these registers properly, without taking out the DS1742W from the TDS3000 board.

Being part of the 2K address space, these "stumbling block" bits can be programmed with a TL866. I have never found the need for more extreme measures. There is a sequence of writes that has to be done correctly, and it is specified in the datasheet.
@meduza, once you get the ball rolling on your side, and it turns out you actually need to do this and need help, I can provide instructions.

The second-life board is very convenient if you have it, but I doubt that the OP does, and anyway his chip is on a socket so easy to move to a programmer.

[meduza]

Thank you, guys!

The problem was a bad contact of the NVRAM's 1st pin. During the surgery I cracked it accidentally. I repaired the chip by soldering it to round female pinheaders, which now acts like new pins.

But at least now we know that non-working or missing NVRAM chip causes TDS3000 stucking on splash screen. The content of a working chip seems doesn't affect the booting. After replacing battery, the NVRAM has all FF's in it, but the scope boots fine.

[meduza]

Hello again. It seems I'm not so lucky. The scope boots, but I have other issues now.

1. It somehow became TDS3012, despite it's supposed to be TDS3052, and it was before I started the journey. Also it has "TDS3052" title on the front panel and on the back near the serial number. Unfortunately, I don't know the prehistory of the scope (maybe it's actually TDS3012 in TDS3052 case). I have two questions:

- How the scope know who it is, where the info is stored?
- Can I determine which model it's actually is by hardware?

2. Both channels became very noisy at sample rates >5MS/s (in either Normal of Fast mode), and also noticeable DC offsets appears, almost exactly like in this topic (where the guys deduced that ADC was bad). I run SPC, it finishes successfully, the noise gone, but DC offsets still there, and they depends on the current vertical scale. After reboot, the noise appears again.

Diag test passed. NVRAM chip seems working, the scope boots, settings are saved between power offs, time is ok. I just don't understand what's going on

[tom66]

All FF in the NVRAM chip likely means factory calibration and configuration was lost.  It would need to be restored somehow, probably by referring to the calibration manual.  Not sure how the model number can be restored, hopefully someone has reverse engineered what bytes do what.

[sicco]

The model number is stored if flash, not in the DS1742W.
The calibration is also in flash.
Both are files, stored in some obscure VxWorks flash file system.

Maybe you broke some PCB traces (from flash roms to XPC860) while desoldering the DS1742W? Looks like writing to flash no longer works.

Quite well possible that by now you will need to reflash the roms, and reload the ds1742w with proper data. Can be done over BDM.

Possibly you ended up with random data in the DS1742W that somehow suggests that it’s a 4 channel unit.

First step: there’s diagnostic start up data on a ttl level serial stream at 38400 baud, on a pin on the 100 pin expansion connector. Explained elsewhere. That may tell you something.  See also https://www.eevblog.com/forum/repair/tektronix-tds3012b-repair-help-needed/

[meduza]

Thanks. Do you know, if SPC calibration stored in flash too? Does the firmware stored in the same flash as model ID and calibration?

It's strange that the scope boots (so the firmware is loaded), but somehow changed its model name and SPC loses after reboot. What even more strange, why SPC fixes noise, but doesn't fix DC offsets, but finishes with a successful message.

[sicco]

SPC calibration result, when it's a pass,  is stored in flash I think. Possibly some of it ends up in the MM9595 also.
Flash for a TDS3000-no suffix and TDS3000B model is two AM29LV160 chips. They have 16 bits data bus, the CPU has 32, so that's why two. The -c models have 32 bits wide data bus flash chip, S29AL032D04.
First try to load a known good binary image in your DS1742W, using a common suitable EPROM programmer. Experiment with all-zeros and all 0xff. Does your RTC actually tick seconds or is it static? Can you set the time/date to the correct time?
And try to capture the boot log as per previous post.

[meduza]

Finally, I found some time to continue troubleshooting the scope.

I've found that pins 11 (WE#) of two AM29LV160B are not connected together. Can anybody check if they must be connected? Thanks.

I also tested my NVRAM chip separately, it works fine in reading/writing zeros, ones, and random data. Clock is ticking.

[sicco]

They are not connected together. One goes to XPC860 WE0, the other to XPC860 WE2.
First step: there’s diagnostic start up data on a ttl level serial stream at 38400 baud, on a pin on the 100 pin expansion connector. Explained elsewhere. That may tell you something.  See also https://www.eevblog.com/forum/repair/tektronix-tds3012b-repair-help-needed/
Second step: get the "2nd life board" or built something like that with a FT4232H or FT2232H mini module. Then you can reflash the roms. And/or detect any issues on address/data busses fro the RAM, ROM, RTC etc.

[meduza]

This is what I get on the serial console (pin 13):

Code: [Select]

excInit called
TBC reset count = 0

I have firmware v2.21. I tried to update the firmware to v3.39 with 4 floppies. The update is compelted without error. Now I have this on the serial:

Code: [Select]

sysClkRateSet using 25 MHz
excInit called

And it still identifies itself as TDS3012. No extra messages appears after I run SPC and diagnosis test.

With the older firmware it successfully passes SPC despite of notable DC offsets, but now it ends with an error (and DC offsets are still exists). Here's error log:

Not very informative though.

Diagnosis test is passes without errors.

sicco, can I read the ROMs with just FT2232H? I don't have the "2nd life board" and BDI3000.

I suspect there's maybe some fault in the ROM, maybe some high address zones aren't working, which may be used for some data storage, and may explain why my scope boots fine, even firmware update was without error, but it still think it's TDS3012. Maybe it just can't read the model number from the ROM and default to the lowest model. The scope also say that it's not calibrated, but it was calibrated ("cal pass") when I bought it. Maybe the calibration and SPC DC offsets also stored in ROMs, although I tried monitoring CE# signal when SPC test is running and CE# is always 1, it goes to 0 only on boot and on "Tek secure memory erase". I also checked every pin on both ROMs with another scope and there's activity on every pin, so it excludes bad connections.

[sicco]

Reading, erasing and reprogramming flash roms is possible with the 2nd life board. Or with just a FT4232H or FT2232H mini module. But then it’s a lot of hassle getting the ~10 wires properly landed at the correct pin on the 100 pin expansion connector. See other posts in https://www.eevblog.com/forum/repair/tds3014-adventures-(seeking-75-75mhz-oscillator)/150/

In your case, i think you have something like a flash file system error. Maybe just ‘disk full’, but maybe something else/worse. Reflashing the roms with what you can read from the roms now will not fix the issue. Brute force overwriting with a binary image will fix it probably. Use a TDS3012 or any TDS30*2 image. But one without suffix. Either firmware 3.41 or 3.39. After that, upgrade to TDS3052 via the well known password and mconfig cmmands over the primary serial port.

For the -no suffix TDS3000 boards, the diagnostics on the serial output is limited to what you now got. Just two lines. But by pulling a pin high (or low?) on the 100 pins expansion port, you get to see much more. The 2nd life boards pull this pin to the right level.
But if you want to just solder wires onto 100 pin connector instead, then:
Try pulling down line SNI_TENA with 4k7 resistor to GND. Pin 67.
Plus pull up line SNI_TX via 47k resistor to +5V. Pin 71.
And pull down line CD also with 4k7 to GND. Pin 53.
Warning: pin number conventions for 100 pin connector can be confusing. Check the pdf / KiCAD files attached.

PS The 2nd life board as in the KiCad and schematics attached can have its own XPC860, flash, RAM and more - but just forget that - or do not populate IC4, IC5, IC7, IC8, IC9, X1. And as you're reusing the old DS1742W with a new battery inside, also no need to populate the DS1744W U2.