Electronics Design AUCM4 on custom carrier board won't enter USB boot mode — rpiboot not detecting it
Asked by stale_biscuit_03 ·
Got boards back from the fab house yesterday — first custom CM4 carrier board, 5 assembled units. Pretty excited to finally have something physical to work with.
Problem: I can't get rpiboot to detect any of them.
Setup: Windows 11 host, downloaded and installed rpiboot from the Raspberry Pi GitHub. Got a USB-C cable connecting the USB OTG port on my carrier to the laptop. I hold the nBOOT_ENABLE button (momentary pushbutton wired to nBOOT_ENABLE with a 10kΩ resistor), power on the board, then run rpiboot. Nothing. Device Manager doesn't change. rpiboot just sits at "Waiting for BCM2835/6/7/2711..." indefinitely.
Board seems to power up fine — I have a green LED on the 3.3V rail indicator and it's solid. Bench supply is showing ~50mA at 5V, which feels way too low.
Using CM4 with eMMC (8GB) and wireless variant, sourced from Farnell. The schematic was based on the Raspberry Pi IO Board reference design.
Is there something obvious I'm missing here? Starting to worry I have a batch of five dead boards.
4 Replies
Not dead boards — almost certainly a boot mode configuration problem. That 50mA figure is the key clue.
When the CM4 is in USB boot mode and actively talking to the host, current draw at 5V is typically in the 300–500mA range. It's running code in the BCM2711, the USB peripheral is active, and it's waiting for rpiboot to send it the boot code. ~50mA at 5V means the CM4 is not in USB boot mode at all — it's doing essentially nothing, which on blank eMMC looks exactly like a silent hang.
What's actually happening: nBOOT_ENABLE isn't being pulled low at power-on, so the CM4 is trying to boot normally from the eMMC (which has no OS on it), failing silently, and sitting idle. From the host side this is indistinguishable from "no device."
Before anything else: measure the voltage on the nBOOT_ENABLE pin with a multimeter while the board is powered on and the button is unpressed. Then measure it again with the button held.
nBOOT_ENABLE is active low — the CM4 enters USB boot mode when this pin is held at 0V during power-on. The correct circuit is:
- 10kΩ pull-up from nBOOT_ENABLE to 3.3V (pin sits high = normal boot by default)
- Pushbutton or jumper between nBOOT_ENABLE and GND (pressing pulls it low = USB boot)
If your button is wired between nBOOT_ENABLE and 3.3V instead of GND, pressing it does nothing useful — the pin stays high regardless.
Also check the nRUN pin. This is the CM4's run enable signal and it must be pulled high (to 3.3V) on your carrier board. If nRUN is floating or pulled low, the CM4 won't run at all. There should be a pull-up resistor — 10kΩ is typical — between nRUN and 3.3V on your carrier board.
The CM4 carrier board design section covers both of these in detail — worth cross-checking your schematic against the nBOOT_ENABLE and nRUN requirements there.
On Windows: when the CM4 correctly enters USB boot mode and rpiboot is running, you should see a new entry appear in Device Manager under Universal Serial Bus devices within a second or two of powering the board. If nothing appears there, the CM4 hasn't enumerated on USB — boot mode entry failed. That's the definitive check before blaming rpiboot.
Measured it. nBOOT_ENABLE is at 3.3V with the board on and button not pressed. With the button pressed... also 3.3V. Doesn't change.
Looking at my schematic: I have the 10kΩ pull-up from nBOOT_ENABLE to 3.3V, and the button connected between nBOOT_ENABLE and... also 3.3V. The other side of the button should go to GND, not VCC. The pin has no path to ground anywhere.
So every power cycle, nBOOT_ENABLE has been sitting high the whole time, and the CM4 has been repeatedly trying to boot from blank eMMC and failing silently. That completely explains the 50mA draw and why rpiboot sees nothing.
Going to bodge a jumper wire from nBOOT_ENABLE to GND on one board and try it. Will report back.
(Update 20 min later: bodge worked. Shorted nBOOT_ENABLE to GND with a wire, powered on, ran rpiboot — it immediately said "found 1 or more devices" and the current on the bench supply jumped to about 380mA. Writing the OS image now. Schematic is going straight into revision for the other four boards.)
Ha — yeah, that one gets people. I had the same thing on my first CM4 board, except I had the pull-down resistor correct to start with, got nervous that "surely an active-low boot pin needs a pull-up not a pull-down," changed it, and then spent the better part of a day convinced I had a dead module. Went back to the pull-down and everything worked immediately. Active-low signals trip people up, especially when the default state is "no boot mode" — it doesn't feel right that the safety resistor pulls away from the special mode.
One more thing to check while you're doing the revision: D+ and D− on the USB OTG connector. If they're swapped, you'll get the CM4 enumerating in Device Manager (so rpiboot will say "found 1 device") but then it'll stall or timeout before sending the boot code. I've seen that twice with USB-C footprints where the orientation in the datasheet wasn't obvious from the symbol. If rpiboot gets past detection but hangs on "Loading embedded." or similar, that's where to look.
The current draw number really is the fastest diagnostic for this whole class of problem. In USB boot mode with rpiboot active, expect 300–500mA at 5V minimum — the BCM2711 is doing real work. Much less than that and the CM4 never entered boot mode, whatever else the software side is reporting.
The general PCB bring-up checklist has a section on current-limited first power-on that would have surfaced this faster — setting the bench supply current limit to what you expect and watching whether it actually hits that level at the right step is a solid habit for new boards.
For anyone else hitting this on a first CM4 carrier board, here's the systematic check sequence before touching rpiboot:
- nBOOT_ENABLE voltage at power-on (boot mechanism not engaged): should be 3.3V. If it's already 0V at rest, the CM4 is trying to enter USB boot mode every power cycle regardless.
- nBOOT_ENABLE voltage with boot mechanism engaged (button pressed or jumper shorted to GND): should be 0V.
- nRUN voltage: should be 3.3V. This must be pulled up on the carrier board. A floating nRUN prevents the CM4 from running at all, which looks identical to a boot mode failure.
- Current draw after engaging nBOOT_ENABLE: expect ≥300mA at 5V if the CM4 entered USB boot mode successfully. Much less than that — like 50mA — means it didn't enter boot mode. Don't proceed to rpiboot if this step fails.
- USB enumeration: Device Manager → Universal Serial Bus → new device should appear within a couple of seconds of power-on. No new device = CM4 not on USB.
- rpiboot output: "found 1 or more devices" with a device count is success. "Waiting for BCM2835/6/7/2711..." with no follow-on means step 5 failed.
If step 4 passes but step 5 fails, check D+/D− orientation on the USB OTG connector (the polarity swap issue grumpy_otter7 mentioned).
Step 4 alone would have short-circuited this whole thread — the 50mA figure was the answer before rpiboot was even relevant.