Intermittent faults seem particularly difficult to diagnose because a circuit may work normally most of the time, making the underlying cause hard to identify.

I’m interested in how experienced electronics enthusiasts approach this kind of problem. Do you start by checking power connections and solder joints, monitoring signals, or looking for changes caused by temperature or vibration?

What methods help narrow down the cause without changing several components at once? Are there any common troubleshooting mistakes that make intermittent faults harder to find?

Thanks for sharing your advice.

 

i always start by overal health assessment, trying to see if there is anything that sticks out such as:
number of layers (single layers are more sensitive/fragile)
pcb mounting/flex/warp
placement of heavy parts (transformers, large capacitors...)
any obvious damage to parts or pcb
check supply (brownouts, stability, noise), if possible power it from lab PSU.
check temperature / hotspots
check spread of events in time from cold start (how long until 1st, 2nd, 3rd etc.)
narrow down the scope (how small system can be - just for diagnostics), unplug anything that is not absolutely essential or substitute where possible.
etc.

if above did not help, try to force failure:
touch/push large components
gently bend/warp board
direct hot/cold air at board/components until problem is found
etc.

 

Being very generalist, it depends on the problem and how many times the problem has occurred.

If you know it's a software/firmware thing, you normally don't go for the hardware, unless you're seeing brown out detection. So the approach is more of what state is before the bug happening, and then setting traps and/or debugging it in real time to see what state it gets to after or before the bug.

If it's more a hardware thing, on a PCB, it's rare to be vibration, I never encountered such problem, but this is me. But yeah, depending on the problem, you go for checking if the temperature makes it happen more often, or if at a lower voltage happens more.
One technique you can use is to apply more than a quantity variation if it's very rare to occur. You apply a hot air gun to the PCB and vibrate the device with small hits and with a lower voltage. Once it appears, you have a more often occurring problem, so it's easier to take a quantity out and verify.

Also, somethings are related to temperature, in a way that the damage has been done by it. The capacitors can be off spec because of long time operation in high temperatures, leaving it at the edge of working.

If it has many flexible wires (not in the PCBs but in devices with wires and connectors), you need to move them a bit to see if there's poor connection.

I've even faced a problem of explosion of the PCB by only 5% of them. So we had to protect against this explosion and search for a PCB that would explode if not protected. Once we found this golden one, we studied it and found the problem to be how the H bridge was being driven. Then we executed a test to see if it would really explode. It did, and we recorded it on camera.

 

properly designed circuit is impossible to damage/destroy by firmware - even if the MCU locks up or firmware starts doing what it is not supposed to.

but... our world is not some Utopia - in fact it is a jungle out there. cost is a major driver and it is all too often that designers are taking shortcuts and handle things in firmware rather than having hardware interlocks.

 

You don’t start replacing components at random.
The worse thing you want to happen is for the fault to go away without knowing what was the problem.

It depends on the equipment, the application, and the frequency of the failure. If the equipment is modular, you substitute one module with a working one.

The first diagnostic approach is to capture the failure with whatever tools are appropriate and available, oscilloscope, logic analyzer, software debugger.

 

properly designed circuit is impossible to damage/destroy by firmware - even if the MCU locks up or firmware starts doing what it is not supposed to.

but... our world is not some Utopia - in fact it is a jungle out there. cost is a major driver and it is all too often that designers are taking shortcuts and handle things in firmware rather than having hardware interlocks.

Yeah. I don't know if you were talking about my saying, but I was talking about firmware bug that doesn't always happen, which mostly happens when you have a real time operating system (RTOS).