TDS540B repair

[cesare]

So, i've embarked on the repair of a TDS540B. This one is in good cosmetic condition, and after some work and tweaking all the controls now behave, and all the channels are working, with SPC succeeding giving me perfectly useable channels.

So if I ignore some issues, it's a working scope...

However, the reality is there are issues lurking, specifically around the area of the EEPROM calibration data, and whatever should be stored in the Dallas chips looks to be potentially dodgy.

The symptoms are a '250 nv storage too small, more bytes requested than available' message in the logs along with 'diagnostic test failure, extended cal librarian reset'. I believe these indicate problems talking to the EEPROMs, so maybe I should be replacing the 24C02s and attempting to backup their current contents...

However, i've dumped the dalas chips, and both dumps fail the checksum tests when 'TDSNvramChecksumVerifier' is run against them (from the tektools github repo).

So my questions for those who've been here before are:

1) Do I first try and track down suitable replacement images for the Dalas chips, and could the fact these are failing CRC checks cause some issues with the EEPROMs to appear (but in reality not be the case)? No point removing and potentially deleting the calibration data if this is the case.

2) I soldered connections to the I2C bus for the 24C02 chips in order to see if the scope accessed them, and what exactly was going on. The results were that there was an initial attempt to read 0xA0/0x08, which succeeded, but a second attempt to set the address to 0xA1 failed was not acknowledged by the chip, and it looks like the scope retries 6 times before failing. Am I right to assume this is a startup problem that is likely to be the cause of the failure to read the calibration data (probably a failed 24C02)?

I've attached images from the first part of the read that succeeds, then the failure case:





If this is the case, i'm not sure which of the two chips the failure corresponds to, but chances are, replacing both is the right course of action in this situation...

3) If I do replace the 24C02 chips, what should I program into them? My understanding is that I can probably dump default calibration values via GPIB, and this is likely to be what the scope is currently running with given the failure i'm seeing at startup? If however, having removed the chips I find that I can extract the data from one of them but not the other, should I mix and match, and use this extracted data for one of the chips and the default image for the other?

4) Annoyingly when the CPU gives up reading the data from the 24C02 chips, it keeps the clock line low, so this means I can't inject my own clock and data and extract the data from the chips after the instrument has booted. Is there any other way to get the instrumented booted up but to keep the processor off the I2C bus, so that I can inject and capture the data with the chips in situ? If so, i'd be able to attempt to extract the data before I desolder them and possibly damage them, giving me another safety net in case I damage them in the extraction process. Could I run the scope, for example, with the link between the processor and acquisision boards removed without causing any problems?




Anyhow, thanks for any advice, and if anyone can point me at clean 540B NVRAM images for me to push into the Dallas chips, that would be a great help (i'll need these even if I do this after the acquisition board replacement)

[cesare]

Digging on the forum for other people who have been in a similar place I came across this successful effort to extract the calibration data from a failed EEPROM, so this would suggest that all may not be lost:

https://www.eevblog.com/forum/repair/attempting-repair-eeprom-voltage-increase-method/msg3011456/#msg3011456

So, current plan is to concentrate on the 24C02 chips, attempt to extract their contents over GPIB (I don't have a floppy on this unit so that's not an option), desolder them, and again attempt to extract their contents with a programmer. It's likely that U1052 (the 0x50 address component that was responding) will play along, and i'll be able to reprogram a replacement for that part. For U1055, there are a number of strategies from thermal cycling/physical stressing and voltage manipulation which will be worth exploring once i've measure it and shown it is at least alive.

[TERRA Operative]

I've had two scopes with the '250 nv storage too small, more bytes requested than available' and 'diagnostic test failure, extended cal librarian reset' errors.

One just needed new 24C02 chips installed which I then used the Tek firmware floppy utilities (available elsewhere on this forum) to extract the calibration data from the 24C02 chips in another scope to load back into the repaired one (just for testing, full calibration is planned soon) and it came good.

The other did not work after swapping the 24C02 chips, I have tested what I can (traced the tracks on the PCB to test for breaks, swapped some logic chips, etc etc) and determined the fault is probably in the ADG368 chip, but all my spare acquisition boards have AGD308 chips, so I haven't been able to test if my thoughts are true (I soldered in an ADG308 but it didn't boot).

[charlyd]

yes this is because of corruption in the 24c02 content.

best choice is to replace with New empty onces, and recal the unit.
cal is made with a computer with NI gpib card and FAS.

[cesare]

Well, i've made some progress.

I've removed the 24C02 chips from the board, and attempts to read them results in a good dump from one (the 0x50 chip) but the second is dead as a dodo. It's not responding to addresses, and appears completely dead. Checking with a meter, it's pulling 250uA at idle, compared to the expected 5uA, so i'm guessing the control logic has got zapped or something like that, and so i'm not hopeful i'll get anything useful from it.

I've got an arduino wired up to the I2C bus and pretending to be the two chips, so I can inject any calibration data into the scope at startup. I'm now looking for some dumps from another 540B so I can at least get further and see where the next problem lies. Injecting the dumped 0x50 chip contents gets me back to basically the state I was previously in, although it does respond as the 0x51 chip, and sends zeroes.

Is there an obvious place to find EEPROM dumps? I've not come across many 540B owners on here, or none that will admit to owning one

[TERRA Operative]

I can help with 700 and some 600 series scopes, but unfortunately I can't help with 500 series...
For some weird reason that I can't figure out, sellers here in Japan ask more for 500 series scopes than 600 or 700 series.... 

If you can find an owner of one with a disk drive, at least they can simply use the disk utility posted elsewhere on this forum to dump the eprom data. Uploading to your scope is just as easy once you install the new chips (I suggest you replace both at once. If one is dead, the other may not be far away. Cheqp enough to just replace both while you have the case open).

[cesare]

Well, if you have an EEPROM dump from a 744A, that's basically the same scope with the colour screen, so that would match, if you have one of those available that would be excellent.

My machine is missing the floppy drive, but I can program the replacement roms with the arduino. I've confirmed I can do this, and as things stand running the arduino on the bus allows me to test out stuff.

I also don't have any info on how the data is structured or checksummed, and as I have what I think is the majority of the data (Well, at least half) so I might be able to splice something together if I understood what the data structure was. The checksum validation tool i've seen in the tektools is distributed as a .jar, not sure if the source is public but that would probably be a help.

Also, I believe I can extract the default configuration from the running machine over GPIB, but my attempt to do this returned just zeroes, not sure why, that's another avenue.

Lots to work through, and i'm not sure what out issues remain!

[TERRA Operative]

Here you go, I dug through my spare parts and found a 744A acquisition board, so here's the cal data from the two chips.
I didn't get checksum errors when using cal data from one scope on another, but I flashed both chips. If you flash both your chips with the data linked below it shouldn't throw checksum errors either.

Hope it helps.

[cesare]

Sorry, just seen this (been busy with other projects and not keeping up with the forums). That's going to be really helpful, thanks for that.

I'll have a play with the instrument + the checksum checker and see if I can bodge something from your dump and what i've recovered from my calibration data. It would be really handy if I understood what the dump contained, but i've yet to see any analysis of the calibration contents, so I might have a quick trawl to see if I can find any description of the data.

[TERRA Operative]

I've never looked into it myself, I'm not a software guy at all so I can't be of much help there.....

[cesare]

Yeah, well i'm a software guy dabbling with hardware, so i'm sort of coming at it from a different direction.

On other news, I picked up a broken 520A as it is in pretty good physical condition, and has a floppy drive, so I thought that would be useful for replacement parts for the 540B (damaged rubber buttons around the screen, a broken foot, missing stand etc). With the floppy i'll be able to run different dump utilities on the 540 which might help me.

Anyhow, I was expecting the 520A to be a mess of dodgy capacitors and lost configuration due to the age of the unit, but the capacitors look reasonable, so no damaged traces I can see. The scope had been put into write mode on the processor board, and the acquisition board link was installed upside down, so a couple of changes and it boots and says it's working. The calibration data is intact, so it's memory is fine, so this turns out to be a good candidate for a restoration too. It has however a failing screen - it works for 15 mins then goes dim and stretched, which i've read is a sign the HV transformer has failed. I'll investigate further, but it's close to being useful. So, i'll try and dump it's settings via the floppy drive, and will try and get this one working too..

[charlyd]

from the 2x 24c02 the second one i not really used.

i would replace them without content from other units, because
the FAS can recal the unit. for you with the right
equiptment

[cesare]

An update.

I've got the 540B into a state where it boots, and no longer has an arduino hanging off the back - i've put config data onto 24C02s which are now fitted, using the recovered config from the main one and the default config for the second one (with the checksum adjusted so it passes). I'm now running into a problem where the display is flickering, and it seems to be VRAM related - the display tests fail with an error when writing to VRAM (I guess storing and reading and getting different data back), but clearly lots of the instrument is working fine, and it sometimes runs for an hour without display problems, then goes all weird and flickery. Even when the display is flickering, you can see the real data, so it feels to me like the acquisition board is doing the right stuff, but dumping the data into the display memory seems to be intermittently broken, could this be a dodgy cap affecting the rails, or a bad chip, or some combination of the two? Not sure where to go debugging this.

Meanwhile, the 520A which was working fully except for the display fading out (so working fine with an external monitor). I decided it was sensible to recap it, since it hadn't been previously done, the processor board went fine, but recapping the acquisition board, i've now got a fault on channel 1. The other channels work well, but channel 1 has a saw wave voltage even when ground is selected, it's around 250Hz or something like that, so i'm guessing i've cocked up with a cap, either reversed, or wrong type, or not soldered correctly, but there are 90 of them or so, so it's hard to know where to start. Any idea what can be channel 1 specific?

These instruments are annoying, I seem to create more problems each time I resolve one