| Electronics > Repair |
| Series defect on agilent 167xx boards? |
| << < (23/50) > >> |
| DogP:
Quick update... I fed a roughly 2 MHz clock into several inputs on the 16750B, and looked at the difference between the regular output and timing zoom output. Attached are a couple screenshots. Notice that only some of the same signals are toggling... and sometimes it's a different set of those pins that toggle (and sometimes none at all). But, the signals that are actually toggling are the only ones that ever do toggle in timing zoom. The other thing to notice is that most of the changing signals toggle every sample (if I zoom into the toggling section, they toggle every 500ps). #16 is the one oddball, that seems to have some sort of lower frequency component, but it doesn't match the frequency, nor time alignment with the actual 2 MHz signal. Other than that, I moved the LA to my workbench closer to the rest of my test equipment, so I could probe it easier. I used the ribbon extender so I could probe both sides of the board, and comparing back and forth between my working 16750A and this 16750B, I haven't found anything that looks out of the ordinary. The signals at the ANDs look fine, and for the most part, everything looks very uniform while running the zoom chip select and acq tests. One nice thing is that they didn't tent the vias on the top side of the board, so they make good test points for the scope probe. I plan to retry the real signal test while probing to see if anything noticeably changes (like actual signal shows up, etc). Also, I'll probably make the 1K probe like you're talking about and test that while running as well. Thanks, DogP |
| DogP:
Interesting update - I tried probing a bunch of pins with my Z0 probe (simply because it's input is 1K to GND). I didn't find much interesting, EXCEPT that probing pin 135 on the FLEX chip causes things to sorta work (either side of the resistor). See attached screenshot. I say "sorta", because the frequency is still wrong, but I consistently see signals on all the pins that have signals, and I never get the error about the WRAP flag. Also, when probing that pin, self-test actually passes the zoomChipSelTest... though fails the zoomAcqTest. But, the only failure it gets on the zoomAcqTest is the edgeCount (no errors about FISO stuck bits), which maybe makes sense, since the output frequency I was seeing didn't match the actual input frequency. --- Code: ---pv> x zoomChipSelTest Slot E: Filling FISOs for Pods #1 with zeroes... Slot E: Checking FISO #4... Slot E: Checking FISO #3... Slot E: Checking FISO #2... Slot E: Checking FISO #1... Slot E: Checking FISO #0... Slot E: Filling FISOs for Pods #2 with zeroes... Slot E: Checking FISO #4... Slot E: Checking FISO #3... Slot E: Checking FISO #2... Slot E: Checking FISO #1... Slot E: Checking FISO #0... Slot E: Filling FISOs for Pods #3 with zeroes... Slot E: Checking FISO #4... Slot E: Checking FISO #3... Slot E: Checking FISO #2... Slot E: Checking FISO #1... Slot E: Checking FISO #0... Slot E: Filling FISOs for Pods #4 with zeroes... Slot E: Checking FISO #4... Slot E: Checking FISO #3... Slot E: Checking FISO #2... Slot E: Checking FISO #1... Slot E: Checking FISO #0... Mod E: TEST passed # "zoomChipSelTest" (13, 5, 1) --- End code --- --- Code: ---pv> x zoomAcqTest Slot E: Chip9: edgeCount=2570, exp=811 > Slot E: Chip9: Zoom Acquisition Data Frequency Test Failed! Slot E: Chip8: edgeCount=2570, exp=811 > Slot E: Chip8: Zoom Acquisition Data Frequency Test Failed! Mod E: TEST FAILED # "zoomAcqTest" (7, 7, -1) --- End code --- Do you happen to know anything about this pin? It looks like it goes to an inner layer, and haven't had a chance to track down where it ends up yet. But suspiciously, it's right next to pin 136-138, which earlier you said are some Zoom chip select pins. BUT, something else that's interesting... I did the exact same test on my working 16750A, and got the exact same result (same pins showed activity at the faster than actual rate). So, hopefully this pin provides some clues, but maybe it actually leads nowhere. :-/ Thanks, DogP |
| DogP:
OK, not quite sure what that pin is doing, but I tracked it to U16 pin 5, through a 316 ohm resistor. U16 is a SY89421V PLL, and pin 5 is the F1 input, which is the loop filter. So... I'm not sure if this is intended to give the FPGA some control over the frequency, or something else. But maybe it's a clue that clocks are a problem... so I'll take a look at the clocks in that area and see confirm everything looks correct. DogP |
| MarkL:
Interesting that it could be a clock issue. I did some poking around and found the clock input on the zoom chips. Here are my updated notes with what I think is on that side towards the pod connectors (any corrections/additions welcome): 1NB4-5040_zoom_capture 144-pin QFP ---- 43 nCS 46 Data bus 48 Data bus 51 Data bus 53 Data bus 55 Data bus 57 Data bus 60 Data bus 62 Data bus ---- 109 Sample data in 111 Sample data in 114 Sample data in 116 Sample data in 117 Sample data in 119 Sample data in 121 Sample data in 123 Sample data in 125 CLKA+ from zoom clock chip 126 CLKA- from zoom clock chip 127 CLKB+ from zoom clock chip 128 CLKB- from zoom clock chip 129 Sample data in 131 Sample data in 133 Sample data in 136 Sample data in 137 Sample data in 138 Sample data in 141 Sample data in 143 Sample data in ---- Notes: Clocks run when capturing, not constant freq CLKA and CLKB are 90 degrees out of phase most of the time Clocks also seem to run when moving data out of the chip Zoom clock distribution chip 1821-4731 Generates 5 pairs of clocks that are distributed to each board Receives clock and clock- from clock chip (itself) through gray cable Fans out clocks (CLKA+, CLKA-, CLKB+, CLKB-) for the 5 zoom chips Each zoom chip gets its own set of 4 clocks Attached are some scope traces of what I found on the clock inputs. nCS makes a good scope trigger input, and the clocks can be found on a tiny resistor pack on the bottom (see photo). The clocks when running are 156kHz. Might be worth a look if you suspect a clocking problem. (Ignore the spikiness in the waveforms. I'm using a long ground wire clipped onto the chassis. Good enough for what we need to see here.) EDIT: Forgot to mention this is all happening while zoomChipSelTest is running. Here is the script: --- Code: ---#!/bin/sh export PVRESULTLEVEL=10 export PVDEBUGLEVEL=9 ( sleep 8 echo "s e" while true; do echo "x zoomChipSelTest" sleep 3 done ) | pv --- End code --- |
| DogP:
Aha! Smoking gun... I started checking the SY89421V pins, and saw the 100 MHz reference at RIN, and checked the S pins, which showed N=10. So, the VCO frequency (output on HFOUT) should be 1 GHz, and FOUT (which is the feedback at FIN) should be 100 MHz. Unfortunately, probing FOUT and FIN showed no visible signal. HFOUT is too high to check on my oscilloscope, so I grabbed the spectrum analyzer. From there, I saw the freq. was actually ~1.37 GHz, which is outside the specified range of the VCO, so it's probably slammed to the upper rail, likely because the feedback frequency is missing (it's saying "go faster, go faster!"). But, when I pull the loop filter down with the Z0 probe, it looks like it slams to the lower rail at around 320 MHz. Apparently, at 320 MHz, the rest of the circuitry can function, though obviously not as expected (but better than when it's way overclocked). As a check, I grabbed my good card, and saw HFOUT at 1 GHz as expected, and also had 100 MHz at FOUT and FIN. So... I guess it seems very likely that U16 is bad. I'll swap it from my 16716A later tonight and confirm that's the (only) issue. DogP |
| Navigation |
| Message Index |
| Next page |
| Previous page |