Tektronix TDS754C Bad 4th Channel Repair - Page 1
Forum section: electronics / repair

author: amaschas
author_rank: Regular Contributor
timestamp: July 20, 2025, 10:14:13 pm
content: After hitting a dead end a few months back, I'm jumping back into a repair attempt on a TDS754C that has a problem with the display of signals on channel 4. The problem manifests like this:Channel 4 with no signal inputChannel 4 with a signalThe error log outputs two errors:Code:diagnostic test failure, digDataFormatDiag1MMem, ERROR!!in demux 200 ,i= 9 memBaseAdr 0x7380014= data = ffff8001, expectedData = 0"Code:Internal adjustment range exceeded, 1.0916 => Balance dac #4 (ID #147)"The first error I've managed to find a fair bit of info about, and appears to relate to the demux process that takes the signal output from the ADCs and stores the signal data in memory arrays. The most common culprit here appears to be a bad SRAM memory IC, and thedemux 200 ,i= 9in the error string refers to the ICs in the 200 range, and the index is most likely referring to the i + 1 IC in the array, so IC 210. The error indicates that the test expected a 0 value from that IC, and instead read ffff8001. I started my investigation by pulling and replacing IC 210 in the 200 series array.To test the memory ICs, I pulled out my trust T48 and ran the test for generic SRAM in the appropriate size, but IC 210 passed with no issues. I also pulled IC 209 for testing, but it passed as well. Having read that the tests the T48 can run on these SRAM are limited, and a more thorough test might turn up something that the T48 missed, I threw together a testing device (I actually ended up building two, one with an Arduino Mega and one with an ESP32) that tested every memory address on the IC, writing and then reading each bit at each address. Both ICs passed this test with no problems.At this stage I thought it might be a good idea to find a schematic, and for this device it seems like the best available reference is the service manual for the TDS520B, which has essentially the same layout but with different SRAM sizing. Looking at the schematic dmux 200, I saw that ICs 209-216 shared address lines with 210, so I started pulling those ICs and testing them. I eventually pulled every IC in the 200 range and tested it, both with the T48 and the full memory test. None of the ICs failed either.This was the aforementioned wall that I hit. I tried some random things like hitting the big IC 200 demux chip with hot air to check for bad solder joints, but with no success. My sense is that at this point, I need to reinstall all of the SRAM and start doing some debugging on the signals running to IC 210, which is going to be a huge pain given that its on the back side of the board. However before I solder all of the SRAM, I'm wondering if anyone has any suggestions for steps I might take while I have all of the chips off.As for the other error, my best guess as to what it refers to is the balance function in the preamp. You can see a line labeled BAL/I here, and in the analog frontend overview, I found this signal comes from the attenuator DAC (or daculator as Tektronix calls them). I took a look at the attenuator DAC, IC U904, and even found some information for it which let me verify a few voltage that it was emitting and they checked out OK. I wasn't able to check the signals from IC U1101, a TL072, since it is also on the reverse of the board, but I decided to wholesale replace the part since I had read about TL072s failing on these oscilloscopes. This didn't resolve the issue unfortunately.So yeah, just wondering if anyone has any additional insight into the problem I'm observering, or has any suggestions. I'll probably use this thread as a log of stuff I'm trying, in case it proves helpful for anyone else.

author: 44kgk1lkf6u
author_rank: Regular Contributor
timestamp: July 25, 2025, 12:52:53 am
content: You did test the power supply right?If a chip has a bad output driver, then maybe the memory tester and the oscilloscope can read out things differently. If you have not yet put the chips back, you can reorder the chips when you put them back. See if the diagnostic message changes. If it points to the same chip, then it may be the board that is broken.A broken trace is not likely. 2 chips share the data lines. As long as 1 of them is connected right, the capacitance should retain the data.I suggest against worrying about the balance DAC problem for now. If some samples are off, then the device can't figure out the actual level.

author: TERRA Operative
author_rank: Super Contributor
timestamp: July 25, 2025, 08:02:55 am
content: I was going to say, it looks like a bad SRAM chip, but you say you tested them.IIRC, the RAM banks don't line up physically with the input jacks?I'm not sure of the order off hand, but maybe you tested the wrong RAM bank?

author: amaschas
author_rank: Regular Contributor
timestamp: July 26, 2025, 08:07:29 pm
content: Quote from: 44kgk1lkf6u on July 25, 2025, 12:52:53 amI actually have not. I figured it was unlikely that a power supply error would only affect a single SRAM on a single channel, but I could be wrong about that. Anything in particular I should look at there?Quote from: 44kgk1lkf6uI actually did re-order the chips as I replaced them, and I am getting errors in different places, but I'm still debugging to determine if that's due to soldering errors or the original issue. Also, is there any way to test for a bad output driver? I really tested the hell out of these ICs, like ran several full read/write tests of every bit in every memory address.Quote from: 44kgk1lkf6uYeah, I think I've basically come to the same conclusion about these two.Quote from: TERRA Operative on July 25, 2025, 08:02:55 amI'm almost certain I'm testing the correct one. The TDS520B indicates that DMUX 200 is the one for channel 4, and I also traced the analog signals from the frontend to the DAC that feeds 200. It would also make sense that I'd be seeing DMUX errors given the way the problem is manifesting. It's just very weird that every SRAM tested out perfectly.I'm currently in the process of (I think) chasing down some errors arising from soldering all the chips back. I've been chasing down the problems systematically. First got an error (all in dmux 200) on i=4 (205), re-soldered that one and it shifted to i=0. I actually swapped 201 and 202 when I removed them just to check if it was the IC, but the error remains on i=0. I'm getting the sense that while the specific error will point to a specific IC, the actual problem can be anywhere in the array of four SRAMs that are being read. If I understand correctly, the way memory is addressed is that each dmux has 4 arrays of 4 SRAM ICs, set to read or write via the WE pin. The scope can only write to one array at a time. So for instance if it wants to write to array 0, comprised of U201, U202, U203, U204, it will pull the shared WE line LOW for all of those SRAMs, and pull all of the other arrays HIGH (or put them in standby via CE1, not sure what it does here), set the addresses for every IC in the array and write them all at once. It can only read or write one array at a time, because the address lines are shared across the arrays.Though now that I'm looking at the schematic, it actually seems like the scope can read or write to two arrays at once, because the 64 IO pins should allow array 0 and 1 to be read/written (though only to the same set of addresses, since the address pins are shared), and the same for 2 and 3. Basically what I'm trying to figure out here is, if I get an error telling me i=0 should read 0, but is reading some other random data instead, and the actual IC at U201 is fine, whether a problem with another IC in that array, or one it shares address pins with, could cause that problem.

author: 44kgk1lkf6u
author_rank: Regular Contributor
timestamp: July 27, 2025, 01:57:23 pm
content: You can measure the power supply voltage with a multimeter. If you want to be safe, try measuring between the VDD pin and VSS pin of every chip. If 1 of them is less than the others by about 400 mV, then the trace may be broken. I just mentioned the power supply because it is so easy to measure. Just like how I ask people to turn the computer off and on again.The bad output driver is only 1 possibility. It can also be the input. It can also be something one did not think can happen. To test for these problems, it is possible to use another oscilloscope to look at the signals. Or after you narrowed down the problem to 1 chip, seeing what removing or replacing the chip does.Maybe it is easier to check for soldering problems with a multimeter. It can also tell that the traces on the board are fine. Running the oscilloscope with the cover open may over heat some parts.If you are not sure about what the diagnostic message means, you can look at the signals with another oscilloscope or logic analyzer.I didn't pay attention at first. But do you know why the data in the diagnostic message is 32 bits when a chip is 8 bits?

author: amaschas
author_rank: Regular Contributor
timestamp: September 14, 2025, 07:10:02 pm
content: Quote from: 44kgk1lkf6u on July 27, 2025, 01:57:23 pmtl;dr I think my problem is the big dmux chip.This question prompted me to do a bunch of reading to understand exactly how the dmux in this machine works. There are still some parts I don't quite get, but ultimate the reason you get a 32bit number is because the value in question is not the value stored by an individual SRAM, but rather by a dmux channel composed of multiple SRAM ICs. The way the addressing works is that the memory address in the error is the logical address the demux uses, and 13 bits of that address are used to address the array of SRAM ICs. So in this case we have an array of 4 x 8bit RAMs (I think the full dmux channel is actually 64 bit, but read in 32 bit chunks), and that array is treated like a single larger logical 32 bit SRAM where each 8 bit segment of the 32 bit word is stored at the same address on each individual IC. So based on the error I received:Code:diagnostic test failure, digDataFormatDiag1MMem, ERROR!!in demux 200 ,i= 9 memBaseAdr 0x7380014= data = ffff8001, expectedData = 0"The test expected a 32 bit word of 0x00000000, but instead read 0xFFFF8001. So knowing that this 32 bit word is stored on 4 different SRAM ICs, we haveSRAM 1: FF instead of 00SRAM 2: FF instead of 00SRAM 3: 80 instead of 00SRAM 4: 01 instead of 00It's worth noting that 80 is 1000 0000 and 01 is 0000 0001. I'm now also sort of thinking that i = 9 is not the bad IC, but rather the spot in the address where the memory value mismatch got thrown. I don't really understand how that applies here, but after shuffling some SRAMs around when I was reinstalling them, I got a new error:Code:diagnostic test failure, digDataFormatDiag1MMem, ERROR!!in demux 200 ,i= 4 memBaseAdr 0x738000a= data = fffffd00, expectedData = aa00"So we can see that the memBaseAdr seems to break down to 0x73800, and 0x0A appears to be the SRAM address, though technically that should be a 12 bit number rather than an 8 bit? I'm also seeing evidence of a test pattern, where the first arrangement failed at 0, but the second got to 0xAA00 before failing.I think the biggest takeaway here though is that I basically have two stuck bytes. The two stuck bytes stayed the same even when I rearranged and replaced some of the SRAMs. The test failed in the same place, and the other two bytes were also wrong in some cases, but the values changes which indicates that those SRAMs can at least be addressed, read and written to, but two of the SRAMs on one of the two 64 bit busses are constantly reading all 1s. This implies that one of the control lines is simply failing to get set at all, resulting in at least one block of SRAMs being either unwritable or unreadable.A bit of additional context here from the 520B repair manual:QuoteI believe what this means is that the There are two 64 bit memory arrays that alternate reading and writing to work around the speed limitations of the SRAM (the dmux can read/write much faster than the SRAM apparently). I'm not sure what the bit about the two 8 bit data streams being split into 16 8 bit data streams.In the TDS 520B repair manual, I can see that the control lines are set up as follows:OE: Connected to one of two pins (labeled OEA and OEB) on the big dmux IC. I believe these are used to switch between the two 64 bit data arrays.CE1: Connected to a single shared CS pin on the dmux.CE2: Pulled up to +5V universally.WE: Connected to one of 4 pins on the dmux (WE0A, WE1A, WE0B, WE1B).I stuck probes on the OE pins of SRAMs, choosing ICs in different 64 bit arrays, and was able to observe the pins getting pulled down in an alternating pattern, which reflects the interleaving approach described in the 520B repair manual. Then I chose two ICs on the bad channel, and the signals were completely missing from what I could tell. I then measured those same signals coming directly out of the dmux to rule out bad traces, and observed the same behavior. So I think that's the mystery solved: bad dmux IC. I need to source a replacement, likely off a donor board since this IC (ADG299G) is a custom Tektronix. Anyone got a spare one they'd be willing to spare?

author: TERRA Operative
author_rank: Super Contributor
timestamp: September 15, 2025, 06:26:05 am
content: I'll see what I have tonight after work. I have a few scrap boards, but no promises I have the chip.....Can you post a photo of your chip so I have a visual reference?

author: amaschas
author_rank: Regular Contributor
timestamp: September 15, 2025, 10:20:30 pm
content: Quote from: TERRA Operative on September 15, 2025, 06:26:05 amOh that would be excellent, thanks for looking! Here's a photo of the relevant ICs. They're the big ones on the right: ADG299G

author: TERRA Operative
author_rank: Super Contributor
timestamp: September 16, 2025, 12:04:25 pm
content: Yep, I got a scrap board with 4 of the chips, PM me and we can work out getting some to you.