• Please review our updated Terms and Rules here

Motherboard debugger

MicroCoreLabs

Experienced Member
Joined
Feb 12, 2016
Messages
273
Hi,

I am considering developing a debugger which would be a CPU drop-in replacement which contains an FPGA and a microcontroller to diagnose motherboard issues down to the chip level. The software would run on an Adruino/Teensy and the FPGA would generate the bus cycles and would communicate with the user via the USB/UART.

The software would first try to access each device on the motherboard similar to existing diagnostic ROMs. But when it encounters a failure, the software will prompt the user to attach a probe wire to the pins of specific ICs to observe if the signal is toggling as expected. If so, the software will ask to look at other signals until the failed component is found so the user can replace it.

The ultimate goal would be for the software to be sophisticated enough to diagnose and isolate failures for every IC on these vintage motherboards without the user needing oscilloscopes, schematics, or
debugging skills.

Any thoughts/suggestions?

Thanks,
-Ted
 
You will have to cater for variations in the circuitry.

I would think modifications and other motherboards could be supported as it would just require updated software while the tester hardware would remain the same...

In fact, if all signals passed through the FPGA then different pinouts could also be supported such as the 6502, Z80, and others...
 
It's been done back when you could still buy 5v tolerant FPGAs
Or, you can kick the CPU off of the bus and do your own bus cycles the way that in-circuit emulators or the Fluke 9010 worked
 
You may start with my Debuggerfor the PC as base of your idea. Instead of the display you can attach a microcontroller or other intelligent device. One thing you can do then is to log how a healthy PC behaves. When running into a bad type of that PC, use the debugger and compare the results with the log of the good one. You can decrease the number of logs by using a diagnostics ROM that fits multiple machines.

This idea can be extended to PCs with PCI slots. But that is, as stated on my site, a bit to sophisticated for me.

The main advantages of my idea is IMHO that you don't have to remove/replace ICs, you use a ready available access, and you can start simple with immediate results.
 
The ultimate goal would be for the software to be sophisticated enough to diagnose and isolate failures for every IC on these vintage motherboards without the user needing oscilloscopes, schematics, or
debugging skills.

Honestly, I don't think that's attainable. Call me a pessimist. Running down the malfunctioning segment of a SSI TTL chip somewhere on the board from the CPU socket is probably not doable, without putting a known board on a bed-of-nails ATE setup.
 
Honestly, I don't think that's attainable. Call me a pessimist. Running down the malfunctioning segment of a SSI TTL chip somewhere on the board from the CPU socket is probably not doable, without putting a known board on a bed-of-nails ATE setup.

The board would have a probe wire(s) which the user would attach to IC pins requested by the debug software. Bus cycles are initiated at the CPU socket and the results are checked with this moveable probe which should allow all components to be tested...
 
I suppose that might be workable with a specific PCB, but how general can you make this?

It could be extended to support any type of processor or motherboard, but for now I am investigating whether there is enough interest to invest time in the project...

I have been watching a number of YouTube debug videos recently where the host has access to a debug ROM, an oscilloscope, and the schematics but still ends up desoldering/replacing multiple chips until they stumble on the broken one. These hosts have debugging skills and equipment greater than the average vintage hardware enthusiast yet they still struggle finding the faulty IC's. The enthusiast is even less likely to achieve success...

What I enjoy about this Forum is how a new user will ask for help debugging their hardware and a number of senior members spring into action posting ideas, suggestions, URLs, and other words of support which often will result in finding the bug. I wondered if there was some way to consolidate/catalog this knowledge into an "expert system" where a cheap piece of hardware could be plugged into the machine and the user would follow steps to track down the fault down to the specific IC. These machines are only getting older, so I believe there could be a growing use for a system like this; especially for users who dont have the time, equipment, or inclination to debug subtle faults.

I'm not sure yet what the best flowchart would be for tracking down failures (Im open to suggestions); but the first step would be to simply test specific IC's on the board. If we want to test the IC which generates RAS/CAS, I would ask then to attach the probe to pin-x of IC-y and hit enter when ready, then I would send a series of bus cycles, or even elongated/distorted cycles, to force activity on this IC which is detected by the probe(s). The Teensy's ADC could also be used to sense the voltage level for mid-level voltages. If success, then I would request another pin or IC be probed, until the faulty IC was found. The next development step would be to integrate these IC tests into a smarter flowchart which would only test ICs in failing paths. (Meaning, if we can access DRAM successfully, then there is no reason to check any IC in this path)

Anyway, this is the general idea... The hardware would probably be a small PCB which replaces the CPU and contains an FPGA to generate the bus cycles and a header for the Teensy 4.0. Probably less than $50 in parts... The complexity would be in the software... But once it is dialed-in just about any fault on the board could be isolated..

Seem reasonable? :)
 
Aren't you assuming that the motherboard clocks and bus interfaces work properly? I could see on semi-functional motherboard how one could isolate bad RAM chips, but a fault in an SSI chip (or something within an LSI chipset) would be a pretty ambitious goal. It's going to be really tough getting past the "it's a brick" type failures.

For example, how would you diagnose a faulty 8288 bus controller?
 
Aren't you assuming that the motherboard clocks and bus interfaces work properly? ... For example, how would you diagnose a faulty 8288 bus controller?

Not really... the Teensy 4.0 has <20ns IO sampling time, so strobes like ALE can be tested and I control the bus interface, so testing each output combination of the 8288 would be easy. It also contains ADC's, so voltage and signal levels could also be tested.

Basically, if you can debug the issue with an oscilloscope, then this system should also be able to detect it.
 
Okay, I'll suspend criticism and hang onto a couple DOA XT boards that I have around here. I'm willing to offer one up for test. I think the task is more than anyone expects.
 
It could be extended to support any type of processor or motherboard, but for now I am investigating whether there is enough interest to invest time in the project...

I have been watching a number of YouTube debug videos recently where the host has access to a debug ROM, an oscilloscope, and the schematics but still ends up desoldering/replacing multiple chips until they stumble on the broken one.

It sounds like you watched this video: https://www.youtube.com/watch?v=SQHt5Ccvn3M

These hosts have debugging skills and equipment greater than the average vintage hardware enthusiast yet they still struggle finding the faulty IC's. The enthusiast is even less likely to achieve success...

I think knowledge and experience on understanding circuits and using instruments probably has more to it. Not sure if an all in one debugger can allow an enthusist's entry. If so, I better look for a new job. However, I welcome more tools for myself! If they can complement standard equipment well.
 
It could be extended to support any type of processor or motherboard, but for now I am investigating whether there is enough interest to invest time in the project...
Enough interest to purchase a ready-to-use product (i.e. you do all development work), or enough interest from people who will be willing to customise the software for particular boards ?
 
I think the task is more than anyone expects.
I agree. With a scope of all chips (and all traces), I see a vast amount of 'diagnostic tree' logic, even for something simple like the IBM PC motherboard.

Basically, if you can debug the issue with an oscilloscope, then this system should also be able to detect it.
See the diagram at [here], in particular, the faulty OR gate at top left. The gate's output is alternating. With my multi-channel oscilloscope (or logic analyser), I can simultaneously monitor the gate's three pins and from that, deduce that the gate is faulty. A single probe will not be enough to inform me that the subject gate is faulty.
 
Enough interest to purchase a ready-to-use product (i.e. you do all development work), or enough interest from people who will be willing to customise the software for particular boards ?

It would be open source, so both are options. Once the hardware and first version of debug software works then others could adapt it to additional motherboards
 
I agree. With a scope of all chips (and all traces), I see a vast amount of 'diagnostic tree' logic, even for something simple like the IBM PC motherboard.

Noted.


See the diagram at [here], in particular, the faulty OR gate at top left. The gate's output is alternating. With my multi-channel oscilloscope (or logic analyser), I can simultaneously monitor the gate's three pins and from that, deduce that the gate is faulty. A single probe will not be enough to inform me that the subject gate is faulty.

In my case, the source of your gate would be driven to a known state by my hardware, so only a single probe would be needed at its output. Note that I have control over the bus and can probe with 20ns granularity throughout the cycle, so I should be able to set gate inputs and observe their outputs within bus cycles. I will probably need two probes though to check for delay-line or clock to out timing in some cases.
 
Back
Top