Electronics > Repair

Series defect on agilent 167xx boards?

<< < (27/50) > >>

MarkL:
On the 16555D failure, I would re-configure both cards to be stand-alone (not as a master and expander), and re-run the self test on each.  This will at least give you an idea if the problem exists with the inter-card communication, or is isolated to one of the cards.

The 16720A doesn't have runners on the bottom, so no surprise it's completely clean.  Is there a little gray ribbon cable installed, and in the correct position for single card operation?

On both failing cards it might be useful to post the results of running pv on the first reported failure (modtest xxxx) with the debug options turned on.  If you haven't used pv yet, use the forum Advanced Search and look for "pv" from user "MarkL".

Glad to hear both your 16534A are working.  I can't say I've had the same luck.  I would recommend removing the plastic runners and adhesive from these and all your cards before you get corrosion problems.  Heat is your friend, and you can search the forum for lots of ways people have done this removal.

I'm not aware of any schematics or detailed troubleshooting for anything from the 165xx/167xx series.  The only thing available is the Theory of Operation section in the Service Guide.  I'd suggest you read those sections and absorb every word.  Although only a summary, they seem have been written by people very familiar with the internal operation of the cards (maybe even by the developers) and are very accurate in my experience.  Combining the information from the Block-Level Theory section and Self-Tests Description section can help make sense of what pv is reporting, and can sometimes lead to you directly to the failing area.

MateKrisz:
Yes, I tested the 16555D cards separately. When I tested it as master-slave combination, the test said a big FAIL for both card. Later I made two primary card, and tested them. so one working and one bad.

On the 16720A the gray ribbon cable is on good postiton. J8 and J9 connected. I checked it in the manual.
I made some pictures about the pv utility output. You see the loopback test output.

I found the manual little info about the self-tests:
Internal Loopback Test.
The internal loopback test verifies the operation of the module backplane interface IC. A walking ones pattern is written into module memory at a specific memory location, read, and compared with known values. Passing the internal loopback test implies the module backplane interface IC is functioning and the system is able to write to module memory.

The clock test is fail also and the wait test too. I think problem with the module backplane interface IC on the board. This chip is the big one like  Altera (U52) near the 50M clock (U72)?

MarkL:
On the 16555D card, I wouldn't bother trying to get it to work in a pair with the good card until you figure out what's wrong with it in the stand-alone configuration.  Please post the pv results for the bad card by itself, both the summary of all tests, and then the first test that failed with debug options turned on.  There might be clues there.


On the 16720A, I don't have much experience troubleshooting that card since mine has always worked.  I agree that it could be the FPGA (the Altera MAX), but there's plenty of other possibilities surrounding it that could be preventing the loopback from working.  Given that some of the other tests are actually passing, I wouldn't be inclined to suspect it right away.

I think I would try to figure out exactly what the system is doing during the loopback test.  The manual says it's trying to write a pattern to memory and read it back.  The first set of debug output implies it is doing byte read/writes.  The only memory I see on the board is the Micron SDRAM (48LC4M16A2) and there are 8 of them.

I would try to find which SDRAM chip(s) it's trying to read/write to by looking at the write enable pins on each.  If you have enough probing capability, you could even try to figure out the data pattern that's being attempted (looks like it might be 0x00, 0x55, 0xff, 0xaa from your diagnostic output).

The manual says 6 of these chips are used for data, so I'm guessing the other 2 might be used for sequence control, and probably it's the two nearer the clock circuitry which would be U121 and U117.  It's only a guess, but you could start your probing with those 2 since the errors being reported are only byte sized.

Another technique to try to localize where the errors are coming from is to lift legs on chips, particularly the memory chips, and correlate it to what new errors start appearing.  Useful signals for this test would be chip select, write enable, and a data I/O line or two (not all at the same time).  This might be a good option, considering how long the loopback test runs (at least couple of minutes on my system).

A similar technique is to hold down various signals with a 50ohm or smaller resistor.  The size resistor can be determined by watching on a scope to make sure you've ruined the switching levels enough to cause an error.

Also note the large number of LVTH245 chips.  My guess is that they are probably controlling access for each memory chip to a common bus, which is how the memory is read and written by the system.  Perhaps lifting a leg or two on these could induce interesting errors that might correlate to the loopback errors.  Maybe one of these is sick, but it depends on how they've laid out the memory addressing.


It's not easy debugging these cards with no schematics and no documentation for the debugging output, especially if you don't have a working card to compare with.  Sometimes it's just easier to buy another card.

MateKrisz:
Hi MarkL,

Thank you for your answer and your tips. I checked again my 16720a board under magnifier, and I found lot of hidden dirty area around the FPGA. Looks like first time I need to wash the PCB with IPA. Some days ago found a topic where the guy has a problem with the oscillator (U72). After I read it I ordered one quickly, I was lucky I found one on low price, and the seller live relative close to me. If the board is cleaned and the oscillator replaced by myself, I will re-run the pv tests maybe something changing. I will tell you the pv outputs here. Some days and the oscillator will arrive.

Tomorrow I will send you the 16555D pv outputs. First time I need remove the plastic things from the back side, and I replace the 4 pcs 3300uF capacitor. Maybe some has bad ESR value.

MateKrisz

MarkL:
Did you test U72 and have determined it's bad?

And test the 3300uF capacitors?

If not, I wouldn't start replacing components without having determined they're definitely bad, or at least you've exhausted all other reasonable possibilities.  Swapping out components can often make the situation worse by inadvertently introducing additional problems.

Can you provide a link to the post about the oscillator?  There are at least two more clock chips on the board that I found (PLLs) if you're looking at the failed clock test.

On the analysis cards, the pv tests are (for the most part) in order of dependency, meaning that a failed test could make later tests also fail.  I don't know for sure, but I would suspect the 16720A pv test routines are structured in a similar way.  That is why I would focus on the loopback failure first.

If you found a post that makes you suspect U72, then sure test it.  But if ok, don't pull it off the board, and return to looking at the loopback failures (in my opinion).

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod