STM32F401CCU6 ROM USB DFU: Check the HSE Detection Path Before Blaming the Application Clock Tree
A board can enumerate as a USB device under its application and still fail to appear in the STM32F401CCU6 system-memory DFU bootloader. That observation separates two initialization paths. The application may know its oscillator frequency explicitly; the ROM must follow its own interface-selection and clock-detection procedure.
This article applies to the STM32F401xB/xC section of AN2606 Rev 70, February 2026, read on 19 October 2026. The STM32F401CC product page identifies that device family. Do not substitute the neighboring F401xD/xE section or infer the MCU from a board nickname. No board, firmware or enumeration test was operated for this explanation.
Identify which software owns the clocks
After a reset into system memory, the ROM initializes its own resources. Table 77 describes HSI use during interface detection. USB DFU execution subsequently requires the external HSE source and a PLL configuration selected by the bootloader.
Consequently, changing an application PLL divider does not change the ROM’s frequency-detection algorithm. A successful application USB session is useful evidence about that application and the connected hardware under its operating conditions. It does not demonstrate that the ROM can identify the source during its separate startup path.
Keep the comparison controlled. A software jump from an already running application can leave a different peripheral state from a reset with the documented boot-selection pattern. Establish the reset-based path first, using the exact part’s supported boot selection. Otherwise, a test intended to isolate clock discovery can accidentally compare two different entry conditions.
Follow the branch after USB selection
Section 35 describes an external frequency from 4 MHz through 26 MHz in whole-megahertz steps. TIM11 participates in determining the HSE value. Figure 45 then distinguishes successful detection, followed by system and USB clock reconfiguration, from failed detection, which leads to a system reset.
The successful branch configures a 60 MHz system clock and a 48 MHz USB clock. These are different clocks; neither should be replaced in the analysis by the application’s configured CPU frequency. The decisive question is whether the ROM reaches the successful branch with the actual external source.
The note also relates detection margin to HSI deviation. It favors lower HSE frequencies and gives 8 MHz rather than 25 MHz as its comparison. That is a relative-margin statement, not a declaration that every 25 MHz board fails or that fitting an 8 MHz crystal guarantees enumeration.
A missing host device can have several causes. The flowchart makes failed HSE detection a documented hypothesis worth investigating; it does not turn every missing USB event into proof of that failure. Preserve reset and connection observations separately.
Establish the physical source and interface path
Record the full marked part, package, board revision, actual oscillator population and schematic. Compare the nominal external frequency with the ROM’s allowed values. A project setting copied from another board is not evidence of the fitted source, and a legal nominal frequency does not qualify oscillator startup, loading or electrical integrity.
Table 77 identifies PA11 as USB DM and PA12 as USB DP. Check those named signals against the actual package and board routing, including the connector path. Do not copy package pin numbers from a different STM32 board. The table says the DFU arrangement does not require an external pull-up; that does not remove the need to review the complete USB circuit.
Figure 45 checks USART activity before its USB branch and also contains I2C and SPI selection paths. Inventory connected peripherals and debug adapters that may drive those interfaces during boot. For a later isolated check, use a documented quiescent arrangement rather than allowing an unrelated sender to select a different bootloader transport.
Design an enumeration-only comparison
Prepare a recoverable development unit and a way to return to the approved normal boot state. Record the boot straps, power and reset sequence, host connection, part identity and source assumptions before attempting the ROM path. Limit the proposed observation to device enumeration and reset behavior. Flash erasure, programming and option-byte changes are unnecessary for this question.
Compare the application path and reset-based ROM path without claiming their clock trees are identical. If only the ROM path fails, investigate its entry conditions, competing interface detection and HSE discovery before modifying application clock code. If both fail, retain the broader USB and board investigation.
A useful result names the last established stage: system-memory entry confirmed, USB selection uncertain, HSE detection uncertain, or DFU enumeration observed. It does not invent a boot-ROM log that the device never provided. The outcome sought is a bounded explanation of the initialization difference, with actual hardware qualification still pending.
