STM32 in DFU mode using system bootloader is not recognized by host PC, or the connection is not reliable. But USB user application works fine.
The problem here might be caused by the HSE crystal, as mentioned in AN2606 (see section 3.1 page 21):
"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)."
If the internal oscillator precision is altered above the tolerance band (1% around the theoretical value) due to temperature or other conditions, then the bootloader might calculate a wrong HSE frequency value. Wrong HSE value is then used for calculation of PLL parameters. That make MCU and MCU peripheral work with unexpected frequency.
In case the bootloader DFU/CAN interfaces are used, incorrect communication frequency is used and in case of DFU, USB host is not able to communicate with such device, which cannot be connected.
Recommended solutions from AN2606
- Use the bootloader with a temperature controlled environment, such as a production line at ambient temperature
- If UART is used, use lower baud-rates at 9600 Bauds to minimize communications errors
- If USB or CAN are used, it is highly recommended to use lower external crystal value below or equal to 8MHz.
The lower the value is, the better the precision of the HSE computation.
Recommended solutions from AN2606 are only decreasing probability of problem visibility, but still cannot guarantee issue will be prevented. Since system bootloader is fixed, no change in its code are possible and only option to prevent described issue is to use custom bootloader in user memory. Bootloader code in user memory can be fully customized and additionally may include security features, which are missing in system bootloader.
