Electronics > Repair
Series defect on agilent 167xx boards?
<< < (42/50) > >>
MarkL:
I agree it looks like a clock failure.  However, I don't think the dead PLL symptoms posted previously resulted in "Analysis Chip Data Bit" errors.  I think in your instance it looks like a data strobe failure between the FPGA (closer to the memory) and the analysis ASIC (closer to the pod connectors).

There's a hefty amount of traces between each FPGA/ASIC pair on the bottom, and I'm assuming you already checked the integrity of those traces.

Note that all the anlyBusTest failures are happening on "Chip 8", which on the 16753A/54A/55A/56A cards is the analysis ASIC associated with Pods 3+4 (U77).  There are no anlyBusTest errors happening on Chip 9, which is the other corresponding ASIC for Pods 1+2 (U76).

So, using this to your advantage, one way to tackle the issue is to compare component values with the corresponding component on the other half of the board.  I've found a number of bad (open) resistors using this method, and I guess capacitors are on the menu now thanks to your latest find.  At first pass, even if you're measuring in-circuit, all you would need to look for is anything that's wildly different from one side to the other.  The actual component value is not so important.

You could also set up a looping anylBusTest and with a scope try to locate anything that looks like a clock on the working Pod 1+2 side, and compare that to the corresponding test point on the broken Pod 3+4 side.  The clock might only be active when moving data.

Your observation that it sometimes eventually gets the test pattern right after a delay may be the result of a clock that's only partially working.  The clock could be running at the wrong logic level due to a bad series or shunt termination resistor, or maybe a bad trace.  Maybe the clock is a differential pair and one leg is dead.

You could also try to force the same error to occur on the working Pod 1+2 side by grounding various traces on that side through a 10R or 20R resistor, while watching the test in a loop with debug on.  I don't know which trace(s) are clock, but I've used this method to home in on non-working individual bits that are reported in the debug output.

I would focus on the "Analyzer Chip Memory Bus Test" failures and not worry about the "System Clocks (J/K/L/M/Psync) Test" for the moment.  The latter test is probably failing as a result of the corrupted path between the FPGA and ASIC (just never say never).
John_ITIC:
Thanks Mark. Much appreciated.

I re-checked all available traces and components around U77 but could not find anything wrong. I have been in touch with DogP and it looks hopeful that I can get my hands on a few of his extender cable adapter boards so I can do further bench testing with my scope on various live signal paths.

I have four of these 16754A boards that fail the pv comparatorCalTest and dappAddrDataTest too. And I know that these are related to the timing zoom, as the GUI calibration also fails. And I get timing zoom errors when sampling with timing zoom turned on. It will be tricky to resolve with the boards inside the 16700 case so I prefer to get the proper extension cable setup.

I can confirm that the anlyBusTest failures only occurs on pods 3 and 4. As an experiment, I fed 16-bit wide ripple counter data from an Altera dev kit (with 0.1" header LVCMOS outputs) to the pods via a flying leads probe. This test shows that I can actually consistently configure and sample data from all pod channels so I know that all data paths are intact. But channels 3/4 have some odd behavior approximately 50% of the acquisitions:

On Ch 3/4, I'm seeing lots of toggling of the bit state before it settles to the correct state. See attached images:

p515: "Bouncy" transitions on channels 3/4
p516: The same capture but zoomed in such that the "bounces" can be seen more clearly.
p517: A proper capture of channels 1/2. Half of the times, channels 3/4 look this way too.

 I have to think some more about what could cause this behavior.

Thanks,
/John.
John_ITIC:
I have a few more key pieces of information regarding the "bouncy" transitions:

1) The bouncy phenomenon starts when the test vectors change from all 1's to all 0's. See attached p518.
2) The trigger does not catch this when triggering on D0 positive edge to D0 positive edge less than 80ns (80ns is the D0 period).
3) The fact that all exhaustive SDRAM pv tests pass fine suggests that this is an issue with the U77 analysis IC, not with the SDRAMs or SDRAM controller.

This tells me that this is an issue with the U77 analysis IC retrieving the data from the FPGA controller IC after capture.

This looks suspiciously like ground bounce, suggesting an issue with the U77 power integrity. Perhaps bad decoupling or bulk capacitors.
https://en.wikipedia.org/wiki/Ground_bounce

I'm investigating further...

/John.
MarkL:

--- Quote from: John_ITIC on February 19, 2024, 05:40:02 am ---...
I re-checked all available traces and components around U77 but could not find anything wrong. I have been in touch with DogP and it looks hopeful that I can get my hands on a few of his extender cable adapter boards so I can do further bench testing with my scope on various live signal paths.
...

--- End quote ---
I also have DogP's extenders and they work well, but before that I did the vast majority of my troubleshooting by putting the target card in slot E, turn the chassis upside down, remove the bottom cover, and safely relocate the mouse/keyboard interface card.  You can get to nearly the entire bottom of the card.  You can get a lot left/right comparisons done this way, and if you're looking for a bad trace, it's most likely going to be on the bottom anyway.

And if you're using remote control, you can completely disconnect the mouse/keyboard card.  The OS doesn't care if it's there or not.
John_ITIC:

--- Quote ---I also have DogP's extenders and they work well, but before that I did the vast majority of my troubleshooting by putting the target card in slot E, turn the chassis upside down, remove the bottom cover, and safely relocate the mouse/keyboard interface card.  You can get to nearly the entire bottom of the card.  You can get a lot left/right comparisons done this way, and if you're looking for a bad trace, it's most likely going to be on the bottom anyway.

And if you're using remote control, you can completely disconnect the mouse/keyboard card.  The OS doesn't care if it's there or not.

--- End quote ---

Thanks Mark. I considered this after reading about your initial setup but since DogP had available extender boards (on the way to me) I'll go for the "proper" bench setup. I'm in no rush to get this system back up and running so will take my time to make my job easier (even if the initial setup takes a little longer) by having the whole board on the bench.

Otherwise, no update on this issue today.

/John.

Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod