Electronics > Repair
Series defect on agilent 167xx boards?
MarkL:
So with your discovery of the 1GHz clock, what I was seeing on the CLK inputs to the 1NB4-5040 zoom capture chips was not making sense. I couldn't figure out why they would go to the trouble of creating a 1GHz clock just to divide it down. I assumed, wrongly, that each chip had its own PLL that somehow synced up to a slower incoming clock. Not so.
My error was that I wasn't looking for a higher speed clock, so I didn't have the scope set up right to see it, and certainly not using appropriate probes. The clocks run to read out the data, and that was not a surprise, but they also run at a much higher speed when capturing the samples. And, as I found out, in zoomChipSelTest, the entire capture interval is much shorter than normal mode, on the order of 2.5us, and very easy to miss if you weren't looking for it in the test cycle of over a second.
So, instead of trying to observe the clocks with a looping zoomChipSelTest in pv, I set the module to repeat a data capture under normal operation. And this time I used Tek P6245 1.5GHz active probes. The 1GHz clock is at the limit of the scope and close to that of the probes, so everything looks like a sine anyway, and a wobbly one at that due to the sin(x)/x interpolation. A much faster scope system is really needed to probe the CLK properly. (And before anyone says it, yes, I should also use shorter grounds.)
Here are a couple of screen shots of the zoom clock inputs while capturing data. As before, CLKA and CLKB are each a differential pair (zoom_clka+_clka-.png). When capturing, CLKA and CLKB are duplicates with no phase offsets (zoom_clka+_clkb+.png). The frequency changes with the inverse of the sample rate. A sample period of 0.5ns (the fastest) runs the CLK at 1GHz, so the chip must be capturing samples on the rising and falling edges.
This is a guess, but maybe CLKA is for one half of the chip and CLKB is the other half. There appear to be two groups of 8 sample inputs and maybe they wanted the chip to be able to capture at different rates with 8-bit granularity in other instruments.
The last screen shot (zoom_capture_readout.png) is one cycle of capture and data download in normal operation mode. The above 1GHz captures are taken during the first waveform interval in the beginning at the trigger marker.
Just puttin' it out there for comparison if anyone needs zoom clock info in the future.
MarkL:
Since I had the probing set up, I went back and took a closer look at the operation of "zoomChipSelTest".
Here is the test being performed in pv with "d d=9 r=9":
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" (380, 0, 1)
Below is the scope capture. The top of the screen shows a zoomed out view of the first segment of the above test for "Slot E: Filling FISOs for Pods #1 with zeroes" through the beginning of "Slot E: Checking FISO #4". The scope trigger was set on CLKB+ pulse width <10ns.
The bottom is zoomed into the first part of the segment. What's shown is a short burst of about 156kHz, maybe doing some set up of registers in the zoom chip. This is followed by 33.6us of the 1GHz clock being turned on, which would be the "filling with zeroes" part. After the 1GHz clock burst, the clock resumes 156kHz to extract the data from the zoom chip. This is repeated 4 times, once for each of the 4 pods in the test. What I think is the nCS pin is only active for most of the data extraction part, so there's probably more to the zoom chip select and read/write that's not understood yet. Maybe it's just a read select.
The sample data inputs change across all the chips before each of the above 4 steps. I didn't do an exhaustive check of all 68 inputs, but in a few spot checks it appears pv sets up the comparators to generate zeroes for the current pod and the rest are set to ones. It then does the capture, gets the captured data from all 5 zoom chips, and then presumably looks to make sure there are only zeroes on that one pod.
There is also a short 2.5us burst of 1GHz on the clock that precedes each test cycle (not shown) that was mentioned in the previous post, but I don't have a good guess what's happening there.
While probing this area, I was also able to see that the FISO numbering starts with #0 at U55 near the edge. On a 16715A/16A it's in the same order starting with #0 at U8. So, if a problem is reported on one zoom chip, you know which one it is now.
Again, just posting the info here for future debugging. It's all guesswork. Any additions/corrections/verification is welcome.
And a side note for all pv debugging: I found out somewhat by accident if you set "d r=10" for some operations, you get even more detail. The help says "r=9" is the highest level needed, but this apparently is not true. Makes me suspicious if there's anything more for even higher debug levels. I didn't see any differences past 10, but who knows.
DogP:
Very cool... great info as always!
BTW, my extension boards arrived, and they work! :) Attached are some pics.
I tested with a pair of 17" long IDE cables, which are long enough to stick out the back of the chassis. I used a 2-drive cable (cables I had nearby) - apparently the extra connector isn't hurting signal quality too much - it gives you a convenient place to probe for reverse engineering the backplane too. ;) I don't have any longer cables here, so I'm not sure what the limit is.
Somewhat surprisingly, it all fits as planned... the connectors tuck between backplane connectors, and doesn't block an adjacent slot. And the cables plugged in at the card don't block access to components near the connector. All of the connectors fit snugly, so they don't feel like they'll fall out, though I put a small screw hole in case you'd like to attach it. Particularly, I was worried if you pull on the card when working on it, it might pop out of the socket. So, I might 3D print a bracket to clamp over the rear connector on the card.
Maybe you could modify a filler panel and leave the cables hanging out the back for when you need to test a board outside the chassis... then you wouldn't need to remove the bottom, or even pull the unit out at all. A 24" cable (or longer) might be helpful for that. Or, maybe add a trap door in the bottom so you can pull the cable out the front, since presumably the front will be facing your workbench, and is probably the most convenient place for debugging a board.
Anyway, I'll post the gerbers, assembly notes, etc. to Github later tonight. But if anyone (US shipping) wants a set, I've got some extras (I ordered 20 boards, since it was only a couple bucks more than 5)... just pay a few bucks for shipping.
DogP
DogP:
Uploaded extension files to Github: https://github.com/pdaderko/16702B/tree/main/card_extension ...
DogP
Hamster:
Repair log for two 1675X Cards...
Card # 1 Zoom/Comp Errors:
Comparators Test running...
...Comparators Test ended. Result: Failed***
ZoomChipSel Test running...
...ZoomChipSel Test ended. Result: Failed***
Image show area of repair: 1675X_COMP_ZOOM_ERROR
Card #2 Errors:
Memory Data Bus Test running...
Slot B, Data Failures, chip 1, bank 1, port 3, Mems U90, U87
< Truncated >
...Memory Data Bus Test ended. Result: Failed***
Dma Test running...
< Truncated >
Slot B, Chip 1: RAM Count Only Unload Test ...
Slot B, Chip 1: Interleaved Data & Count Unload Test ...
Slot B, Chip 1, SDRAM U71:
< Truncated >
Slot B, Chip 1: Interleaved Data & Count Unload Test Failed!
> Slot B, Chip 1: DMA Unload Modes Test Failed!
Slot B, Chip 1: Bad RAMs: U71 Bad Data: 0x3FFF
...Dma Test ended. Result: Failed***
Memory Sleep Mode Test running...
Slot B, Chip 1, SDRAM U74:
Slot B, Chip 1, SDRAM U71:
Slot B, Chip 1: Bottom bank check failed before Sleep mode.
...Memory Sleep Mode Test ended. Result: Failed***
Image of areas of repair: 1675X_MEMORY_ERROR
--- Card # 2 had prior repairs with rails removed, the card had developed additional failures after sitting. ( Note, there were "Chips" in error, but the repairs were not even in the area or memory controller )
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version