Chronicles of MCU Troubleshooting: The Floppy Emu Mystery

August 30th, 2026 | Category: Floppy Emu | Author: Steve

When a microcontroller circuit starts acting up, how do you actually track down the ghost in the machine?

A few months back, I produced a fresh run of Floppy Emu disk emulators. However, a portion of the batch failed Quality Assurance (QA) at the factory. The symptoms were bizarre—unlike anything I had encountered in the entire development history of the device.

The Symptom Matrix

The failures weren't uniform; they fell into three distinct categories of "weird":

Given my deep familiarity with the ATMEGA1284 and the surrounding Floppy Emu architecture, I usually have a "gut feeling" about these things. I wondered: Are these three separate bugs, or a single systemic failure?

My intuition pointed toward a systematic assembly error. Since my contract manufacturer had engaged a new subcontractor for this specific batch, I suspected a silent change in the production process had introduced a flaw.

---

Probing, Poking, and Theorizing

After these boards sat on my desk for months, I finally dove in, starting with the "won't boot" group—the most straightforward problem to isolate.

The Debugging Checklist

• Connect boards to a test harness.
• Verify power rails.
• Connect hardware debugger.
• Reflow solder joints (to rule out cold joints). $\rightarrow$ No change.
• Verify MCU configuration and programming.

The results were inconsistent:

1. On most boards, the debugger could communicate with the MCU. The chip was programmed correctly, but the code simply wouldn't execute.
2. On a smaller subset, the debugger couldn't even detect the chip.

Maybe it was a bad batch of chips? To test this, I desoldered an ATMEGA1284 and swapped it with a known-good spare. After programming it, the board still refused to boot.

The "Caveman" Approach

I began to suspect that the program was crashing during the initial handshake with the CPLD or SD Card—steps that occur before the display initializes. To verify this, I bypassed the fancy tools and went back to basics: LED debugging.

I modified the source code to trigger a "proof of life" sequence:

void main() {
    // Caveman Debugging: Blink LED 20 times immediately
    for(int i=0; i<20; i++) {
        digitalWrite(STATUS_LED, HIGH);
        delay(100);
        digitalWrite(STATUS_LED, LOW);
        delay(100);
    }
    // ... proceed to SD Card and CPLD init ...
}

The Result: Absolute silence. No blinking. No activity.

Since this blink happened at the very start of main(), it effectively ruled out failures caused by external components like the SD Card. I was left with only two culprits: the reset signal or the clock.

---

The Mystery of the Clock Crystal

The Floppy Emu relies on an external 20 MHz crystal for precision. However, the ATMEGA also possesses an internal 8 MHz oscillator.

Since the debugger could still talk to the chip, I decided to experiment with the fuse configuration. I switched the clock source from the external crystal to the internal oscillator.

The result was immediate: The device booted! It ran normally, albeit at a fraction of its intended speed.

The Math of the Slowdown

The performance drop can be expressed as: $\text{Performance} = \frac{f_{\text{internal}}}{f_{\text{external}}} = \frac{8\text{ MHz}}{20\text{ MHz}} = 0.4$ This explains why the "sluggish" boards were running at exactly $40\%$ speed.

Logic Flow of the Discovery

Technical Root Cause

The ATMEGA series uses an internal amplifier to drive a piezo crystal, creating what is known as a Pierce Oscillator. While I'll admit I'm not a theoretical expert on the physics of Pierce Oscillators, the practical reality is that you connect the crystal's terminals to two specific pins.

If this circuit is compromised, the MCU lacks a heartbeat. It will either stay dead (The Bricks), glitch out (The Haunted), or—if it manages to limp along—run incredibly slowly (The Sluggish).

Visual Evidence

Physical board inspection.

Standard ATMEGA crystal wiring.

The oscillator circuit in question.