uConsole CM5 Power Delivery: Why the Keyboard Locks in DFU Mode and How to Fix It
Why the keyboard locks up in DFU mode
When the uConsole keyboard re-enumerates as Leaflabs Maple DFU (USB ID 1eaf:0003) and stops responding, that is not a software bug. The STM32 microcontroller on the keyboard board has hit its brown-out detection threshold and jumped to the factory DFU bootloader, where it sits waiting for a firmware image that will never arrive. That is why USB unbind/rebind, toggling authorized, and every other software trick fails: the MCU is not crashed. It is in a deliberate recovery mode. Only a power cycle gets it out.
The Maple bootloader normally opens an 8-second DFU window at startup. In this failure mode, the window becomes indefinite because the MCU keeps resetting into it as long as the rail stays marginal.
The uConsole power chain and where it breaks under CM5
The uConsole runs from a lithium cell at roughly 3.7V nominal, stepped up to 5V through an on-board boost converter before feeding the rest of the system. That single 5V rail supplies the compute module, the USB ports, the keyboard, the display backlight, and the audio section. Under the CM4 this arrangement held up. The CM5 changes the math.
Real-world measurements put the CM5 at significantly higher peak current draw compared to the CM4 under sustained CPU load. The boost converter has to work harder. And at lower states of charge, when the cell voltage drops toward 3.5–3.6V, the converter needs a higher duty cycle to maintain the output. That is where things start to unravel.
Transients are the actual trigger
Boost converters regulate well under steady loads. Fast transients are another problem. Plugging a device into the USB port causes a capacitive inrush spike on the 5V bus. If the converter’s output capacitance is modest and its control loop is slow to respond, the rail droops briefly below the brown-out threshold of the keyboard MCU. That droop can last just a few milliseconds. It does not need to last long.
At a full charge the cell is closer to 4.2V and the converter has margin. As the cell discharges, that margin disappears. A spike that would have been absorbed at 90% charge now drags the rail below threshold at 40%. This is why the problem worsens as the battery runs down, and why a high-power USB-C supply connected to the charge port does not fully solve it: the bottleneck is the boost stage between the battery and the 5V rail, not the charge rate.
The audio hiss is the same problem
Audible hissing from the speakers at low battery is not a separate issue. Boost converters switch at a fixed frequency and produce output ripple at that frequency. When the converter is working near its limits, the ripple amplitude grows. The uConsole’s audio output shares the 5V rail, so that ripple couples into the analog signal path as noise. A cleaner supply rail reduces the hiss without touching the audio circuit at all.
Mitigations, from fast to involved
Bulk capacitance on the 5V rail
The quickest hardware intervention is adding low-ESR bulk capacitance directly on the 5V rail, as close to the keyboard connector as possible. A few hundred microfarads of polymer or aluminum electrolytic capacitor gives the rail a charge reservoir to ride through a hotplug inrush event without drooping far enough to trigger the MCU’s brown-out detection. It does not fix the underlying converter limitation, but it can absorb enough of the transient that the keyboard never sees it.
Placement matters more than most people expect. A capacitor soldered to a convenient 5V/GND test point in the middle of the board is worth less than one right at the connector, because PCB trace inductance between the two is enough to isolate them during a fast transient. Find the 5V pad closest to the keyboard header and work from there.
One practical consideration: USB PD specifications place limits on total bulk capacitance on VBUS to avoid tripping port protection on the host side, but for capacitors placed downstream of the boost stage output (not directly on the USB-C input) this is generally not a concern.
Underclocking the CM5
Reducing the CM5’s maximum CPU frequency lowers sustained current draw, which gives the boost converter more headroom between transients. It does not eliminate the hotplug spike, but it reduces how close to the edge the converter is running in normal operation. Some users find that throttling the CM5 in /boot/config.txt keeps the system stable on battery where full-speed operation caused disconnects. This is cheap, reversible, and worth trying before any hardware work.
Replacing the boost converter
This is the root-cause fix. The stock converter was sized for CM4 current envelopes. A replacement with a higher peak current rating and better transient response lets the 5V rail stay clean under CM5 loads without depending on bulk capacitance to compensate.
Before starting, you need the board schematic to identify the specific IC. ClockworkPi has released hardware files under GPL v3. Once you have the part number, look for a pin-compatible replacement with a higher switch current limit and faster loop bandwidth. The output capacitor will likely need to change too, since the replacement may have different stability requirements.
This level of rework means hot-air or a fine-tip iron on a densely populated board. An incorrect replacement that overshoots the output voltage can damage the CM5. If you have not done SMD rework before, exhaust the bulk capacitor approach first. It addresses the same symptom with far less risk.
Confirming the fix with measurements
A USB oscilloscope, or even a cheap logic analyzer with voltage measurement, will show you the 5V rail during a hotplug event before and after any modification. You want to see how deep the droop goes and how long it lasts. The target is keeping the rail above the keyboard MCU’s brown-out threshold through the entire transient. The exact threshold depends on the specific STM32 variant on your keyboard board, but keeping the rail above 4.5V through a hotplug is a reasonable working target.
If you add bulk capacitance and the droop is now shallow enough that the keyboard stays enumerated, you are done. If the droop is still crossing threshold, either add more capacitance or start looking seriously at the converter itself.
Sources
- jms1.info
- jeffgeerling.com
- forums.raspberrypi.com
- bret.dk
- static.leaflabs.com
- usb.org
- medium.com
- github.com