Hi all.
This has nothing to do with PCs, but for units with a processor, ram, firmware rom, watchdog, fplga, reset circuit and peripheric DSPs; where the rom is typically loaded to ram and executed at power-on.

What techniques are convenient to follow, after confirming presence of power supply, clock, reset, data and address lines activity ? What if there is no activity on data lines; or keeps resetting; or halts, ...?

Buses carrying signals to multiple chips make uncertain the verification and discerning the failure. Any methodical suggestions please ?

Miguel

 

I really don't understand what you are asking. What I gathered is, you are interested in diagnosing problems with systems that have boot-rom loaded into RAM for execution. How can you diagnose failures when there are so many data buses to various peripherals?

I guess the only real method to solving a difficult problem such as that is to know what you are supposed to be seeing on the lines, and what you actually have. You would require an innate understanding of the software and require access to these signals for a logic analyzer.

Steve

 

Yes, gathered well.
If you want to troubleshoot a non-booting gadget, schematic on hand, what sequence of diagnosis steps are to be performed ?
Miguel

 

Hi Miguel,

IMHO, I don't believe there is a fixed process to troubleshoot something of this nature without a true understanding of the gadget itself. From a basic viewpoint, and as you said, you can only really determine if all the ingredients for the circuit are functioning as usual. The clocks, chip enables, etc. should be present.

This is why logic is pre-built into PCs to indicate particular problems, such as faulty/no memory present, no video present, etc. It will beep according to a sequence, which is documented in the user manual for the motherboard.

If you are talking about signal integrity, that's a whole different story. You can probe the data-lines and look for reflections and try different termination resistors or schemes to get it right.

Maybe someone else can give you a bit more useful information about this.. When I cannot pick out an obvious problem with a board and do not have a perfect understanding about how it actually works, then I don't really bother trying to fix it.

Steve

 

I concur with ScubaSteve. Back when my cohorts and I used such diagnostics for troubleshooting, each routine was quite unique to the device. No point in checking for a non-existing feature, right?

Be very aware: diagnostics which fail indicate something very specific is wrong, but diagnostics which pass indicate nothing whatsoever!