Skip to content
Tech News
← Back to articles

Adventures in Microcontroller Circuit Debugging

read original get Hantek DSO2D10 Digital Oscilloscope → more articles
Why This Matters

This story offers a candid look at the unglamorous but critical work of hardware debugging, showing how manufacturing changes—like swapping subcontractors—can introduce subtle defects that are hard to diagnose. It matters to the tech industry because it highlights the fragility of hardware supply chains and the detective work required to maintain product quality, a concern relevant to any company relying on contract manufacturing.

Key Takeaways
Worth a Look

Hantek DSO2D10 Digital Oscilloscope — When you're chasing bizarre microcontroller misbehavior like clock glitches or intermittent boot failures, a hobbyist oscilloscope is invaluable for actually seeing what's happening on the crystal oscillator and power rails. It's the kind of tool that turns guesswork about 'haunted' circuits into concrete waveform evidence. A great companion for anyone doing serious embedded debugging like in this article.

See Hantek DSO2D10 Digital Oscilloscope on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

How do you go about troubleshooting a misbehaving microcontroller circuit? A few months ago I manufactured a new batch of Floppy Emu disk emulators. A number of them failed QA at the factory, with a set of symptoms that I’d never seen before in all my years of developing this device:

Most of them simply wouldn’t boot up at all, despite verifying that power was good and the mcu was correctly programmed.

Some exhibited “haunted” behavior, seemingly jumping to random sections of the mcu program code, outputting messages on the display that made no sense given the context.

One of them appeared to work in slow motion, with LED blinking and display updates noticeably more sluggish than normal.

This was odd, to say the least. I have a lot of experience with the ATMEGA1284 microcontroller and the Floppy Emu circuitry that surrounds it, and I’ve become an expert at guessing what’s wrong based on the symptoms of misbehaving boards. These were all new and bizarre symptoms to me. Might they arise from different problems, or could they all point to one common underlying issue?

My intuition suggested some kind of systematic assembly problem. My contract manufacturer used a new subcontractor for this batch of Floppy Emu boards, so maybe a silent change to the process caused an unexpected issue? Parts substitution? Bad parts? Counterfeit chips? These QA failures sat in a pile on my desk for months, waiting for answers.

Probing, Poking, and Theorizing

Yesterday I finally decided to concentrate on the “won’t boot” devices, since that seemed like the most tractable problem. I put a few boards in a test harness, and connected power and a hardware debugger. The power supply voltages looked good. No obvious soldering problems were evident, but just to be sure I reflowed the solder on a few boards, without seeing any improvement.

On many of the boards, the hardware debugger could talk to the microcontroller and I was able to confirm the chip was correctly configured and programmed, but the program didn’t seem to actually run. At power-up the boards did… nothing. And with a smaller number of the boards, the debugger could not communicate with or even detect the chip. What could cause these symptoms? I brainstormed:

Bad power. Seemingly ruled out by my measurements.

... continue reading