TDS 754D - Diagnostic Test Acquisition Fail

[Tony_G]

Hi All,

I just got my 754D and upon running the full self tests I get a "FAIL ++ Acquisition" error.

The specific error text seems to be "Error: diagnostic test failure digAcqMemAddrDiag, addr = 0x7300000 exp data = 0x1..." (I can't read the end of it because the wrapping doesn't work and it disappears off the screen.

Has anyone run into this before? I can't seem to find any information on it but from the sound of it, it seems to be related to the acquiaition memory.

Everything else reports as fine.

Thanks,

TonyG

[chihaxinh]

Hi Tony_G
Replace all smd cap in acq mainboard ! Check leaky and clean pcb if need !

[Tony_G]

Thanks. I'd heard that the 700D series doesn't have the cap issues that they did in the earlier ones. Is that not actually the case?

TonyG

[Tony_G]

Worked out how to get the full text from the error log (:ERRLOG:FIRST? & :ERRLOG:NEXT?)

  MON OCT 03 20:11:51 2016 
  ERROR: diagnostic test failure, digAcqMemAddrDiag,
  ** addr = 0x7300000  exp data = 0x101  actual = 0x6161,
  ** addr = 0x7300002  exp data = 0x202  actual = 0x6262,
  ** addr = 0x7300004  exp data = 0x303  actual = 0x6363,
  ** addr = 0x7300010  exp data = 0x505  actual = 0x6565,
  *** WAS TESTING DIG B ***

It looks consistently like there is something stuck in the memory where the first 4 bits are locked into the pattern 0110

0x6262 - 0110 0010 0110 0010
0x0262 - 0000 0010 0110 0010

No idea what Dig B is or what IC the address refers to but I don't think it's a cap issue.

TonyG

[eKretz]

From what I understand even the 7xxA series should be good to go as far as caps. I've seen it mentioned that by the time the 7xx series scopes came out they had moved away from the problem caps.

[AndyC_772]

The 754D has a few dodgy caps on the serial/parallel board, but not elsewhere.

[Jwalling]

Worked out how to get the full text from the error log (:ERRLOG:FIRST? & :ERRLOG:NEXT?)

  MON OCT 03 20:11:51 2016 
  ERROR: diagnostic test failure, digAcqMemAddrDiag,
  ** addr = 0x7300000  exp data = 0x101  actual = 0x6161,
  ** addr = 0x7300002  exp data = 0x202  actual = 0x6262,
  ** addr = 0x7300004  exp data = 0x303  actual = 0x6363,
  ** addr = 0x7300010  exp data = 0x505  actual = 0x6565,
  *** WAS TESTING DIG B ***

It looks consistently like there is something stuck in the memory where the first 4 bits are locked into the pattern 0110

0x6262 - 0110 0010 0110 0010
0x0262 - 0000 0010 0110 0010

No idea what Dig B is or what IC the address refers to but I don't think it's a cap issue.

TonyG

Not a cap issue.
Likely one or more bad SRAM chips on the ACQ board. Also possible that it could be a fractured solder joint on one of the 308 lead SRAM controllers. If you runt the test on the ACQ board long enough in a loop, you may get lucky and it will pinpoint the defective chip by reference designation. You should be able to determine which channel is causing the failure by running each one with maximum memory depth set and applying a sine wave signal. look for the channel with noise or artifacts of some sort.

[Tony_G]

Thanks - I can't seem to find a schematic to help decode the address (there are 4 blocks of 8 SRAMs on the board) - The addresses breakdown as:

0x7300000 - 0111 0011 0000 0000 0000 0000 0000
0x7300002 - 0111 0011 0000 0000 0000 0000 0010
0x7300004 - 0111 0011 0000 0000 0000 0000 0100
0x7300010 - 0111 0011 0000 0000 0000 0001 0000

The SRAM chips are IDT 71024S12TY which are 128K x 8 so each chips is serving back a byte. So there are two SRAM ICs involved in returning 0x101/0x6101 with one of them being the one that seems borked.

I'm trying to find which one but I'm not noticing any glitches on the capture...

TonyG

[AndyC_772]

Do the individual devices have separate chip enables, write enables, or some other strobe that controls each byte lane individually?

If so, can you temporarily strap them high one at a time, and see which addresses report as faulty in the self test?

[Jwalling]

Thanks - I can't seem to find a schematic to help decode the address (there are 4 blocks of 8 SRAMs on the board) - The addresses breakdown as:

0x7300000 - 0111 0011 0000 0000 0000 0000 0000
0x7300002 - 0111 0011 0000 0000 0000 0000 0010
0x7300004 - 0111 0011 0000 0000 0000 0000 0100
0x7300010 - 0111 0011 0000 0000 0000 0001 0000

The SRAM chips are IDT 71024S12TY which are 128K x 8 so each chips is serving back a byte. So there are two SRAM ICs involved in returning 0x101/0x6101 with one of them being the one that seems borked.

I'm trying to find which one but I'm not noticing any glitches on the capture...

TonyG

Actually, there are 4 blocks of 16 SRAMs for each channel. Both sides of the PCB are populated. Does the scope currently have option 2M enabled?

[Tony_G]

Thanks - I haven't removed the board so I didn't notice the other side being populated - The scope has the 2M option installed. Does 2M cause the second side to be loaded?

TonyG

[Jwalling]

Thanks - I haven't removed the board so I didn't notice the other side being populated - The scope has the 2M option installed. Does 2M cause the second side to be loaded?

TonyG

All the TDS700 series had both sides populated, whether they used 32K x 8 or 128K x 8 SRAMs. The 700C was the first that offered 2M, but unless it shipped that way they were only populated with the 32K chips. The 700D series from serial prefix B030 and up were all populated with 128K chips no matter what memory option it shipped with.

EDIT: B040 and up used burst type memory in quad flatpacks, IIRC.

I would suggest going through each channel one-by-one setting the memory depth to 2 million points per channel. Then with a sinewave applied try varying the vertical and horizontal settings and input frequency till some anomaly can be seen. I've never seen one of these scopes with failing ACQ memory not display some oddity or another. Until you at least determine which channel has the problem a repair would be difficult - imagine replacing all the SRAMs! 

Also, have you tried running the ACQ tests in a loop for a few hours to see if the scope will pinpoint the failure? Sometimes you may get errors like this:
ERROR !!U307 MemAddr = 0x734600c data = 0xdb exp = 0x16  ,
ERROR !!U306 MemAddr = 0x734600a data = 0x37 exp = 0xac  ,
ERROR !!U305 MemAddr = 0x7346008 data = 0xee exp = 0xd8"

[k1mgy]

Wonder if the battery backed NVRAM might be causing you trouble.  That's just a wild guess.  Experts might chime in here...

[Jwalling]

Wonder if the battery backed NVRAM might be causing you trouble.  That's just a wild guess.  Experts might chime in here...

Nope. He has a hardware failure.

[Tony_G]

Thanks J

Just worked out how to get the test to loop - I'll run it a bunch of times and see what happens.

TonyG

[Tony_G]

Actually spoke too soon - All I've managed to do is to change the loop value on this screen:



When I try to press any button other than "Once" I get a chime - I can change the loop value shown on the "Loop 1 Times" to whatever value I like but pressing it just does a chime.

What am I missing here? I checked the manuals I have but nothing for "Loop" or "Diag/Err" shows references to this screen.

TonyG

[Jwalling]

Yeah, you can't use a looping function with the scope that way. I think Tek never fully implemented that properly.

I use a Prologix USB to GPIB controller which looks like a serial port so it makes it easy to write little .cmd scripts like this:

Code: [Select]

REM tested on TDS784C serial which claims 5 minutes to run SPC
REM A TDS754D with option 2M takes 48 seconds. THIS WAS ON A UNIT WITH FAILING ACQ MEMORY ON CH1!
REM AFTER THE TWO BAD MEMORY CHIPS WERE REPLACED, THE TEST TOOK 100 SECONDS

REM SET address:
echo ++addr 15>COM3

echo CLEARMenu>COM3
echo DIAg:SELect:ACQUISition>COM3

:begin

echo DIAg:STATE EXECUte>COM3

REM We'll use ping as a timer to an unreachable host.
REM
REM Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
REM         [-r count] [-s count] [[-j host-list] | [-k host-list]]
REM         [-w timeout] target_name
REM 
REM Options:
REM     -t             Ping the specified host until stopped.
REM                    To see statistics and continue - type Control-Break;
REM                    To stop - type Control-C.
REM     -a             Resolve addresses to hostnames.
REM     -n count       Number of echo requests to send.
REM     -l size        Send buffer size.
REM     -f             Set Don't Fragment flag in packet.
REM     -i TTL         Time To Live.
REM     -v TOS         Type Of Service.
REM     -r count       Record route for count hops.
REM     -s count       Timestamp for count hops.
REM     -j host-list   Loose source route along host-list.
REM     -k host-list   Strict source route along host-list.
REM     -w timeout     Timeout in milliseconds to wait for each reply.
REM
REM The following will yield 100 seconds which is about the time it will take to run ACQ only test on a 700D:

ping -w 100000 -n1 1.1.1.1

echo CLEARMenu>COM3
goto begin

[Tony_G]

Well I ran it for quite some time and I finally got some errors in the format you mentioned:

ERROR !!U302 MemAddr = 0x7380102 data = 0x60 exp = 0xfd  ,
ERROR !!U301 MemAddr = 0x7380100 data = 0x60 exp = 0x7a  ,
ERROR !!U302 MemAddr = 0x7380082 data = 0x5f exp = 0xe2  ,
ERROR !!U301 MemAddr = 0x7380080 data = 0x5f exp = 0x45

Now the Address is different but I think it's close enough for me to take a stab at replacing those ICs - Of course they're on the bottom of the board so I'll need to disassemble the scope.

Will check back in with the results.

TonyG

[nctnico]

Try to reflow the chips first. Flux will be mandatory and hot-air very benifical because these kind of packages are a PITA to solder with an iron.

[Jwalling]

Well I ran it for quite some time and I finally got some errors in the format you mentioned:

ERROR !!U302 MemAddr = 0x7380102 data = 0x60 exp = 0xfd  ,
ERROR !!U301 MemAddr = 0x7380100 data = 0x60 exp = 0x7a  ,
ERROR !!U302 MemAddr = 0x7380082 data = 0x5f exp = 0xe2  ,
ERROR !!U301 MemAddr = 0x7380080 data = 0x5f exp = 0x45

Now the Address is different but I think it's close enough for me to take a stab at replacing those ICs - Of course they're on the bottom of the board so I'll need to disassemble the scope.

Will check back in with the results.

TonyG

Good deal! 

FWIW in the past, I've seen a larger than expected failure amounts on the 128K chips. I've repaired some scopes that had more than one  bad as well, which you also seem to have. Do check the solder both on the chips, and the memory controller.

[Tony_G]

Thanks NC & JW - I have a rework station, plenty of flux, actual smd solder paste and an arse load of kapton tape to keep things in place.

I ordered the replacements (actually 6 of them) from DigiKey, so I'll wait till they get here to do the reflow first and then try and replace them.

Do you remember what the controller chip designator is? I'll try a reflow on that as well.

Unfortunately I've been unable to find the component level service manual for the 754D which has this information in it. Any additional help appreciated.

Thanks,

TonyG

[Jwalling]

Thanks NC & JW - I have a rework station, plenty of flux, actual smd solder paste and an arse load of kapton tape to keep things in place.

I ordered the replacements (actually 6 of them) from DigiKey, so I'll wait till they get here to do the reflow first and then try and replace them.

Do you remember what the controller chip designator is? I'll try a reflow on that as well.

Unfortunately I've been unable to find the component level service manual for the 754D which has this information in it. Any additional help appreciated.

Thanks,

TonyG

There's 4 memory controller chips. They are the flatpacks with 308 pins each.
AFAIK, there are no schematics available.

[nctnico]

Unfortunately I've been unable to find the component level service manual for the 754D which has this information in it.

Look at the TDS520B component service manual. Tektronix has re-used as much as they could between in the TDS500/600/700 series scope so even though it is not the exact same model there is still a lot of information which can be used.

BTW: Also read the thread in the test equipment section about a TDS784A repair. In that one it appears dry joints on one of the QFP chips where the problem.