An ADG368, an ADG368, my kingdom for an ADG368......
So, dealing with a recalcitrant TDS754D here that apparently lost its cal constants from the EEPROMS (U1052 and U1055) on the acquisition board.
I've had luck replacing them in the past, but this time I can't read or write anything to or from them using the EEPROM/NVRAM read/write utility stuff from somewhere on the forum that I put on floppy disk (It works on another working scope so my disks are good).
I replaced the EEPROMS with brand new ones and then tried writing the cal data from another TDS754D to at least get something force-fed in there but no dice...
So taking a look at the schematic, the EEPROM write control pins are tied to a 74HC86, which receives 5v from the famous 'Write Enable' switch on the processor board, via a 15V to 12V vreg and voltage divider.
All voltages test ok, so I replaced the 74HC86 because it was easy, still no dice. hmmmm.
I have also double checked all traces for continuity, all perfect like the day it was born.
So, the I2C data comes from a 160-pin chip, ADG368. Hmmm, all my spare boards use ADG308 chips. Well, lets get the hot air gun out and swap to see... No boot. Shiet, incompatible.
Swap back and we are booting again but errors are back to square one. So I think the ADG368 chip is most likely the bad bit at this stage (or whatever is feeding the AGD368..) I'll have to scope the I2C lines to the EEPROM chips too, to see if there is activity there.
Now, about finding another ADG368.........
Last resort, pull good EEPROMS full of cal data from a scrapped TDS754D, stick them in and hope it works, if so, call it good.
I also want to rig something up to directly read the data from the old EEPROMs to see if they might actually still be good, maybe something is just stopping the disk utility (and hence the scope) from seeing the data.
How can I do that with the bare chips in my hand? I have a bunch of programmers and chip clips etc but I'm not up with writing and reading directly to I2C chips...
Any idea what that 12V does?
My guess is that some version of NVRAM needed it for writing.
The 12V is brought down to about 5V with a voltage divider to provide 5V to the Write Protect pin on the EEPROMs to put them into write protect mode.
It also goes through some other bits and pieces of logic and ends up connected to the write protect pins on the NVRAM's.
Do you mean the 12V line from top of R2009?
How many NVRAMs there are?
Ah, my bad. That arrowhead on the 'NVWR_EN/I' is actually the line going to the NVRAM's, there are two of them, one containing the RTC.
Ok.
I'm a bit lost with names, types and sizes.
X24C02 is a pure serial E2PROM of 256x8 bytes.
Somebody extracted stuff from DS1650Y partitionable NV SRAM of 4M bits
and DS1486 RAMified Watchdog Timekeeper of 128k bytes.
TDS700x FAS
has low and high NVRAM addresses starting from 0x10 instead of 0x00.
tex = LOW_NV_RAM_ADDR("67108880")
tex = HIGH_NV_RAM_ADDR("67633168")
Relative starting addresses being 262144(256k) and around 131072(128k).
Different stuff being around 327680(256k + 64k).
VAR = hwAInstrSerialNumberDigit(UNIT "" VALUE 327685)
VAR = hwAOption1M(UNIT "" VALUE 327686)
VAR = hwAOptionMathPak(UNIT "" VALUE 327689)
So some models have clearly had two DS1486 chips since RTC and Watchdog are using first bytes
and write protected and NVRAM marked X24C02 chips are very small.
A11 board schematics is naming write protect switch for flash and NVRAM.
Then TDS700x FAS, it seems, is using name NVRAM for everything.
If those not X24C02 MVRAMs are stuff of swapped boards then CRC error is clearly for X24C02, otherwise not.
Can the U1050 be so dumb that X24C02s are read through it?
Pretty far fetched, I know.
U1050 has SDOUT/SDATA pin27 that is going nowhere, like are WNR and ALE, but they are also test points.
Maybe you can get some status data out from that pin.