This article addresses the following issue: using the built-in system bootloader, the STM32 device is not recognized by the USB host in DFU mode, or the connection is unreliable, whereas the USB interface in user applications functions normally.
This root cause of this issue might be the HSE crystal, as mentioned in AN2606 - Introduction to system memory boot mode on STM32 MCUs (see section 4.1, page 34):
"For STM32 devices embedding bootloader using the DFU/CAN interface in which the external clock source (HSE) is required for DFU/CAN operations, the detection of the HSE value is done dynamically by the bootloader firmware and is based on the internal oscillator clock (HSI, MSI). When (because of temperature variations or other conditions) the internal oscillator precision is altered above the tolerance band (1% around the theoretical value) the bootloader can calculate a wrong HSE frequency value. In this case, the bootloader DFU/CAN interfaces can malfunction, or not work at all."
Recommended solutions
- Use the bootloader in a temperature-controlled environment, such as a production line at ambient temperature.
- If UART is used, use lower baud rates, such as 9600 baud, to minimize communications errors.
- If USB or CAN are used, it is highly recommended to use an external crystal with a value below or equal to 8 MHz. The lower this value, the better is the precision of the HSE computation.
These recommendations reduce the probability of the issue occurring, but still cannot guarantee that the issue will be prevented. Since the system bootloader cannot be modified, if its features are not compatible with the application, the only way to circumvent the described issue is to use a custom bootloader in user memory. A bootloader in user memory can be fully customized and may also include additional security features, which are missing in the system bootloader.
