Author Topic: In circuit testing of SRAM on TEK DSA 602A  (Read 1178 times)

0 Members and 1 Guest are viewing this topic.

Offline dcharetteTopic starter

  • Contributor
  • Posts: 15
  • Country: cz
In circuit testing of SRAM on TEK DSA 602A
« on: December 12, 2016, 11:21:14 am »
Hello folks,

I've got an older Tek DSP scope, a DSA 602A.  And upon power up, it goes through some diagnostics routines before it's ready to operate.  There's a slew of PCBs in the unit, and for the most part, it's worked flawlessly for me for many years until recently.  There is what appears to be a memory readback error on the main processing board.  Particularly, it's an error that shows corresponding to the data RAM for the signal processing board.  And I believe, it's the RAM that's used for the acquired signal data.  There aren't any schematics available for the unit, but there is a pretty comprehensive service manual discussing theory operation and troubleshooting, but no schematics... Tek probably had the the intention the user would do board level troubleshooting and swap out PCBs for the repair of the more difficult sections of the unit.

The error in case anyone has specific knowledge of this beast is G2622, which corresponds to the 2nd tristar processor section. In particular, it appears under the Tristar 2 RAM saying at address F7F6, expected data is AAAA, but actual is AA2A.

So, what I know at the moment, is that I believe there to be an actual SRAM memory location that's corrupt. Just one bit that is.  I've gone through the 8 SRAMS in the tristar 2 processor region, and I probed each of the data lines on them, and found them to be healthy it seems.  In other words, nothing dead pulled low or high, and seemingly passing data.  The SRAMS are 32k x 8, and there are 8 of them total for each of the 2 tristar processors, (so 16 total for 512kB or 256kB per processor.)  The data lines appear to be paralleled into a bank of 4 of them and in the service manual it states that they're arranged in 4 groups of 2 for each processor. I would suspect since it's two distinct paralleled groups, the RAM is read in 16bits at a time.

I ran the self test for both the RAM 1 section and RAM2 section, in continuous loops and then simultaneously shorted each data line on the SRAMs to ground, and then observed the self test value on the screen to see what happens, to see if I could positively identify which SRAM would contain the corresponding memory location that's throwing the error.  I figured that once I got to the data bit on the offending chip and shorting it, I would see a change on the screen of what's being written and then read back and the data going in and out on a good SRAM would be exactly the same.  I've only shorted them low, and I may have to pull them high as well to determine the offending one with absolute certainty since it appears the dead bit is actually pulled low... i.e. writing the pattern of AAAA and then reading back AA2A... seems it's bit 7 that is reading back low. 

So anyway, this is my reason for writing.

I wondered if anyone had some experience with an SRAM actually having a single dead bit somewhere? It seems rather odd to me this could happen, but I suppose statistics are at play here and there's always a chance just due to the shear number of transistors operating internally to a typical SRAM.  But being this is SRAM used as a holding space for acquired data RAM, a single dead bit somewhere would have minimal effect of the end measurement, and certainly wouldn't prevent the machine running it's core firmware and operating seemingly healthy.

And if you've had experience with an SRAM failure, how would one go about finding the offending chip without access to schematic or any memory map to know precisely the arrangement of the memory layout?  And, on top of that, is there a way to diagnose and locate the particular chip with the fault, quick and simple with minimal test equipment and time?  I do have a logic analyzer I could throw at it, but with probably a lot less time, I could simply identify the bank at least of SRAMs, and swap them all of at once with very little time invested.

While I'm interested in getting the problem solved, I'm also interested in definitively finding exactly what the problem is and not just shotgunning it and hoping for the best.

Any ideas?

Thanks!  :)

Dan
 
 
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf