| Electronics > Repair |
| Series defect on agilent 167xx boards? |
| << < (41/50) > >> |
| aeg:
--- Quote from: MarkL on October 25, 2023, 10:57:23 pm ---Unfortunately I don't have any extra pod cables, but sometimes they can be repaired depending on the location of the break (assuming you're talking about the coax ribbon cable). --- End quote --- Yeah, the coax ribbon cable. What's the repair technique? |
| John_ITIC:
Hi Everyone. I have studied this thread in detail as I'm going through all my 16717A and 16754A LA boards to fix the rail corrosion. The 16717As were quite easy to fix as mostly the usual trace corrosion. One had a via break so took some time. On one of my 16754As, I have however found a new failure scenario, which is that the SDRAM leads next to the plastic runners are corroding to the point where there are memory errors during the pv 'dataBusTest' test. I discovered this by touching up the solder on the leads/pads to get rid of some brown "crust" and corrosion around the pins. This made the pv 'dataBusTest' fail although the board previously had tested fine all the way up to the timing zoom calibration tests. When removing the SDRAMs mentioned in the pv dataBusTest (the ones closest to the bottom runner) I noticed the multiple leads were extremely fragile and bent and fell off very easily during cleaning. My theory is that they were almost corroded off and that the thermal shock from the soldering iron caused some pins to crack. I checked the two SDRAMs on the opposite side on the bottom side (next to another runner) and two leads broke off there too. I have replacement ICs on order and will see if that makes the dataBusTest and subsequent data-related issues go away. https://www.mouser.com/ProductDetail/Alliance-Memory/MT46V16M16TG-5BMTR Note: The replacement memory is capable of higher performance but will behave the same when clocked at the same speed and CL. Replacement: speed grade 5B: 133MHz to 200 MHz. Original: speed grade 75: 100 MHz to 167MHz. Thanks, /John. |
| John_ITIC:
Replacement of the corroded SDRAMs fixed the pv SDRAM related test failures. I have found yet another failure scenario: shorted out decoupling capacitors under the SDRAM controller IC. Per the attached image, there should be 51 ohm across the resistor. If it is 3-6 ohm or so, then check the nearby decoupling capacitors for shorts. Check resistance from the pads of the resistor that measures a few ohms to the nearby decoupling capacitor pads. If a dead short on both sides (resistor to decap) you know its on the same power rail. Then remove one capacitor at a time until the resistor short goes away. Confirm by measuring resistance of the decoupling capacitor. I had one at 3 ohm and one at 6 ohm. I replaced four on two separate boards and they were all 100 nF 0603's. Note: If all the SDRAMs in the same side of the board fails 'x dataBusTest', then suspect shorted power rails like above. |
| MarkL:
That's an interesting failure on the capacitors. Thanks for posting the troubleshooting procedure. How did you figure it out? Also interesting that there's a lot less of those capacitors under the other ASIC (U126). Almost all of the channel acquisition circuitry on these boards is duplicated with respect to the left and right, including the resistor you're pointing out. Just wondering why one side wouldn't need the capacitors. |
| John_ITIC:
Regarding the bad capacitors: I found some bad that were not near any plastic runner so it's likely they went bad (a few ohms series resistance) over time for other reasons. I essentially checked every resistor and capacitor for reasonable values and also compared with a good 16754A board. I am now next dealing with a failing anlyBusTest. The verbose pv test log is attached. The 16754A service manual says: "Analyzer Chip Memory Bus Test. The purpose of this test is to check the Analysis chip memory busses that go between the Analysis chips and the SDRAM controller FPGAs." So, I assume this test is utilizing the SDRAM controller to read data from the SDRAMs. As the dataBusTest, addrBusTest and other SDRAM related tests have already succeeded, we can rule out bad SDRAMs. The anlyBusTest.txt file shows that the expected data mostly appears some 16 cycles after it is expected. In synchronous logic, this can only be explained by one piece of logic running at a lower clock frequency than intended. As the clksTest is also failing, I'm suspecting that some board clock is running at a slower clock rate than expected. This could explain why the data appears later than needed. But, I don't yet understand how the clock distribution works on these boards. All I know if from the service guide: "System Clocks (J/K/L/M/Psync) Test. The purpose of this test is to verify that the four clocks (J/K/L/M) are functional between the master board and all Analysis chips, and that the two Psync lines (A/B) are functional between the master board's Analysis chips and all Analysis chips in the module. This test verifies that the four clock lines (J/K/L/M) are driven from the master board and can be received by all Analysis chips, and that the Psync lines can be driven by each master chip on the master board and received by all other Analysis chips in the module." I know, from reading earlier posts, that there had been some prior faults with the clock distribution or PLL chips on these boards. Perhaps that is what is going on. I will re-read to refresh the topic. But, if someone has had a similar issue, I would appreciate receiving some more bread crumbs to follow. Thanks, /John |
| Navigation |
| Message Index |
| Next page |
| Previous page |