2025-10-23 8:22 PM
Hi everyone,
I’m working with a custom made STM32F446ZET6 board that otherwise functions perfectly (all peripherals, flash programming, etc. work fine). The only thing that doesn’t is the ROM bootloader. I can’t get USB DFU or UART boot to respond no matter what I do.
BOOT0 = 1 (3.3 V) at reset
NRST pulled high, no reset loops
VDDUSB = 3.3 V, decoupled with 100 nF
HSE = Abracon ABLS-8 MHz-12 pF, started with 18 pF load caps and lowered to 10 pF as I saw in a post here this might be the cause
PA9 connected directly to VBUS (5 V)
PA11/PA12 wired to USB-FS D−/D+ (verified routing and continuity)
Board runs normal firmware from Flash with no issues
BOOT0=1, reset → USB never enumerates
Tried UART boot (PA10 RX, PA9 TX, 115200 8E1) → no ACK, completely silent.
Verified with ST-Link under reset:
RDP = 0xAA (no protection)
MEMRMP = 0x0, VTOR = 0x0 → seems like it’s still mapping main Flash, not System Memory.
Jumped to 0x1FFF0000 manually via GDB/OpenOCD:
Program counter at 0x1FFF503C, D+ line goes high, so bootloader code definitely runs.
But USB still doesn’t enumerate.
D+ rises high after the jump (so FS pull-up activates), but host never recognizes the device.
Everything else on the board, including USB device mode under firmware (Marlin/ Klipper) works fine.
What could cause the internal System Memory bootloader not to fully start USB DFU or UART?
Is there any condition (clock, pin, option byte, etc.) that can block the ROM bootloader on F4 from initializing peripherals?
Has anyone seen a case where the bootloader starts (D+ goes high) but host never enumerates?
Any other hardware requirement besides VBUS > 4 V on PA9 and VDDUSB = 3.3 V that could prevent enumeration?
Any insights would be appreciated. I can share schematics or test logs if needed.
Thanks,
2025-10-24 1:04 AM
How is the BOOT1 pin (PB2) configured?
It needs to low to enter the DFU bootloader mode.
2025-10-24 3:31 AM
hello @samprince
I tested Nucleo F446ZE development board (MB1137) by first setting the BOOT0 pin to a high level (3.3 V) and then performing a system reset(reset using the reset button). After the reset, I connected the USB cable to the CN3 connector (USB PORT) and plugged it into my PC.
Under these conditions, the board was detected in DFU mode by STM32CubeProgrammer, and the USB bootloader operated as expected without issues.
Additionally, I verified that the BOOT1 pin is either left floating or tied to ground, which is essential to ensure that the system memory is selected as the boot area when BOOT0 is set high.
This configuration ensures that the MCU boots from the internal system memory (ROM bootloader) rather than from user flash or SRAM.