| Electronics > Repair |
| Series defect on agilent 167xx boards? |
| << < (36/50) > >> |
| dorkshoei:
--- Quote from: MarkL on March 25, 2023, 08:47:47 pm ---Understood. I left my runners off, and I dislike conformal coatings passionately. Time will tell if I'm wrong. --- End quote --- I'm fairly accident prone by nature and just pulling the cards out over the last couple of days I had to be very careful as they *WILL* clash against each other (with the runners removed). My logic is that (if you read the webpage on replacing the runners) it was speculation by the 3M app engineer that this tape would work best. I figure conformal coatings (I used silicone) are well proven wrt traces so I doubt very much they will cause an issue and maybe if there is a long term issue with the replacement 3M tape it will help prevent damage. Of course it took 20+ years for the issue to occur with the original OEM tape so I suspect I'll be well into senility before anything happens but ...... --- Quote from: MarkL on March 26, 2023, 06:00:17 pm ---On the 16534A card again... Besides the previous question on the self-test, are the cal errors associated with one channel or both? --- End quote --- Both. I just removed the runners from the failing board. It still works (both channels) connected to my Siglent function generator. I tried a variety of waveforms and pulsing. All worked. Maybe slightly noisier than the fully working one. I just re-ran calibration and didn't get the previously mentioned 'whoa this board has issues are you sure you want to continue' message and this time Trigger Delay passed but ADC, Gain and Offset still fail on both channels. Same calibration T cable works fine on the other card. --- Quote ---You can probe two cards at the same time by using a 16701B expansion chassis, or a home-made card extender. User DogP has some gerbers available for an extender that works well: --- End quote --- I'd seen this before. I assume by "two cards at same time" one is via removing the unit cover. I'd like a 16701B. One of my units came with the cable to connect. They're stupid expensive. Max I'd pay is $50 and it would need to be local. I'm parting out a couple of 16700Bs. I think one has opt-003. I've had zero luck selling them for $100. Just mentioning it in case anyone wants any parts (for spares). I'll probably keep the boards from one for spares for my 16702B. I also have a 16702B that will be for sale (two logic cards (low end) with original runners replaced, all cables/pods, optional pattern gen card) if anyone is interested. |
| MarkL:
--- Quote from: dorkshoei on March 26, 2023, 09:18:52 pm --- --- Quote from: MarkL on March 26, 2023, 06:00:17 pm ---... Besides the previous question on the self-test, are the cal errors associated with one channel or both? --- End quote --- Both. I just removed the runners from the failing board. It still works (both channels) connected to my Siglent function generator. I tried a variety of waveforms and pulsing. All worked. Maybe slightly noisier than the fully working one. I just re-ran calibration and didn't get the previously mentioned 'whoa this board has issues are you sure you want to continue' message and this time Trigger Delay passed but ADC, Gain and Offset still fail on both channels. Same calibration T cable works fine on the other card. --- End quote --- It's good that you're getting a waveform showing that the sampling and horizontal stuff is working. That can be really difficult to troubleshoot. Does the offset work? Can you make it trigger on different vertical points on the waveform edge? And if either does work, are they displaying a sane voltage? I'd check out the regulator outputs. There's also some reference voltages common to both channels that are generated by the opamps near the DAC (U200). You can compare with the working card. Here are a few probe points that might help: https://www.eevblog.com/forum/repair/series-defect-on-agilent-167xx-boards/msg3994748/#msg3994748 Problems with the DAC, trigger, offset, and reference circuitry would show up there. If it's noisy, maybe you have another bad cap on one of the voltage rails? --- Quote --- --- Quote ---You can probe two cards at the same time by using a 16701B expansion chassis, or a home-made card extender. User DogP has some gerbers available for an extender that works well: --- End quote --- I'd seen this before. I assume by "two cards at same time" one is via removing the unit cover. I'd like a 16701B. One of my units came with the cable to connect. They're stupid expensive. Max I'd pay is $50 and it would need to be local. I'm parting out a couple of 16700Bs. I think one has opt-003. I've had zero luck selling them for $100. Just mentioning it in case anyone wants any parts (for spares). I'll probably keep the boards from one for spares for my 16702B. I also have a 16702B that will be for sale (two logic cards (low end) with original runners replaced, all cables/pods, optional pattern gen card) if anyone is interested. --- End quote --- Well, the trick is to get two cards powered up at the same time, and depending on the problem, configuring them the same or start them looping on the same test. Sounds like you have enough chassis to do it. I only have DogP's extender recently. I've done most of my debugging from the underside by removing the bottom cover and mouse/keyboard card which exposes the bottom of the card in Slot E. Almost all the signals on the logic analysis cards appear on one of those solder blob probe points on the bottom either because the signal transits there on a trace, or it's brought there on purpose for probing. But it's not so on the scope cards and sometimes jumpers or access to the top is needed. |
| dorkshoei:
--- Quote from: MarkL on March 26, 2023, 10:09:10 pm --- Well, the trick is to get two cards powered up at the same time, and depending on the problem, configuring them the same or start them looping on the same test. Sounds like you have enough chassis to do it. --- End quote --- I'd prefer two extension setups so both cards could be side by side on the bench outside of the unit. Ideally there would be an extender card that slides into the chassis and then you could connect a ribbon cable to that and then the card-under-test to the ribbon cable. Avoid having to open the cover (or grope inside to make any connections). Of course a card this size is mostly empty space, would be $$$ to fab. |
| ahakman:
--- Quote from: MarkL on March 25, 2023, 08:08:24 pm ---Wow, another dead PLL. Can you see any clock output from the dead one? The PLL can be had on any of the 167xx cards with Timing Zoom except the 16715A. It might help to know your country for anyone who can scrounge up a PLL. --- End quote --- I was going to check the PLL output with a spectrum analyzer, but I thought first I would do a quick experiment of swapping the chips, so I didn't actually measure the bad PLL yet. I suspect it's the same as the previous failed one in this thread - the data on the self test looked right, but clocked wrong, so I'm guessing it was running too fast / lost loop control just like the previous failed one did. I'm in the US for anyone that might have a donor PLL board. --- Quote from: MarkL on March 25, 2023, 08:08:24 pm ---It's really better to check continuity via to via on all the traces running through or near corroded areas. Extremely sharp probes pushed into the via holes at an angle works well. On multiple occasions I've had traces with no visible breaks and it turned out the corrosion had gotten under the soldermask. It can take some time to do the testing. But you're right, it could also have eaten away the via hole plating, and that's happened to me too. --- End quote --- Yes, I probably need to get some better sharp probes for my DMM. I have fluke probes, but they have really crappy (worn) tips. I also have the push-on finer probe tip adapters that go over regular fluke probes - they're not exactly the sharpest, but they do poke through the solder mask on the vias with some prodding - having some nice sharp probes would be a nice upgrade though. --- Quote from: MarkL on March 25, 2023, 08:08:24 pm ---The HP-UX based analyzers are able to turn on detailed debugging output when running any of the verification tests (pv). Is there any more detail from the windows version on which bit(s) and/or chips are failing during "Memory Unload Modes Test"? --- End quote --- Yes, on the windows analyzer, you can turn up the verbosity of the self tests to 9, which I think is equivalent to the max verbosity you can set in pv as well. I don't remember exactly now what the error is, but it's either a consistent byte missing, or a consistent word missing. I also seem to recall getting different results running the tests in order from the beginning to the unload test, vs running some tests after the unload test and then going back to the unload test. It still fails in the same way, but it seems to fail for a lot more data values if I come back to the unload mode test after running other tests further down - maybe it's just because of what data has been left in the memory from the other tests. It is interesting to me that the memory address and data bus tests pass, so all of the paths from the memory controller FPGAs to the DRAMs are good, but a consistent failing byte or 2 bytes in the unload test sounds like a control signal problem between the memory controller FPGAs and the back plane CPLD/FPGA (whatever it is) --- Quote from: MarkL on March 25, 2023, 08:08:24 pm ---On the 1675x cards I think the acquisition memory access path from the backplane is through one of the FPGAs near the backplane connector (I think it's the Altera MAX), up to the Virtex FPGAs on top, and then back down to the actual DRAM chips. On the 1671x cards, it goes direct from the backplane controller FPGA to the memory chips (there are no Virtex FPGAs acting as a memory controller layer). --- End quote --- |
| MarkL:
--- Quote from: ahakman on March 27, 2023, 09:33:59 am ---I'm in the US for anyone that might have a donor PLL board. --- End quote --- I have some hopeless cards and can send you a PLL if you want to email me a self-addressed shipping label. Send me a PM and we can work out the details. --- Quote ---Yes, I probably need to get some better sharp probes for my DMM. I have fluke probes, but they have really crappy (worn) tips. I also have the push-on finer probe tip adapters that go over regular fluke probes - they're not exactly the sharpest, but they do poke through the solder mask on the vias with some prodding - having some nice sharp probes would be a nice upgrade though. --- End quote --- I have a pair of Pomona 6275 with the SS tips. You can also get them with pogo tips, but the SS tips are not spring loaded and you can really jam them into the soldermask if needed. Replacement tips are available. They're great when they're working, but one down-side is that they tend to go bad after too much flexing where the wire enters the probe body. I'm on my third pair. Some people like the ProbeMaster 8152/8153 and I might try them next. For probe sharpening, I found this (thanks to your previous pointer): https://northridgefix.com/product/grinding-stone-to-straighten-and-sharpen-tweezers/ It's a sharpening block with a slot in it which makes sharpening the SS tips fast and easy. --- Quote ---Yes, on the windows analyzer, you can turn up the verbosity of the self tests to 9, which I think is equivalent to the max verbosity you can set in pv as well. I don't remember exactly now what the error is, but it's either a consistent byte missing, or a consistent word missing. I also seem to recall getting different results running the tests in order from the beginning to the unload test, vs running some tests after the unload test and then going back to the unload test. It still fails in the same way, but it seems to fail for a lot more data values if I come back to the unload mode test after running other tests further down - maybe it's just because of what data has been left in the memory from the other tests. It is interesting to me that the memory address and data bus tests pass, so all of the paths from the memory controller FPGAs to the DRAMs are good, but a consistent failing byte or 2 bytes in the unload test sounds like a control signal problem between the memory controller FPGAs and the back plane CPLD/FPGA (whatever it is) --- End quote --- Hmmm... I could be wrong about the testing path, or maybe only some of the signals are routed through the Virtex. I'll have to take a closer look at that. Because the same test fails in different ways it implies something could be floating because it's severed. |
| Navigation |
| Message Index |
| Next page |
| Previous page |