Unable to use DFU method of built-in Bootloader for firmware upgrade

1 Introduction

This article will analyze the problem that customers cannot use the DFU method of the built-in Bootloader to upgrade the firmware.

2 Problem Description

The customer used STM32F205VET6 and made a minimum system test board. When connected to the PC with BOOT0=1 and BOOT1=0, the DFU device could not be detected using the PC software DfuSeDemo. However, the firmware could be upgraded through serial port 1 in the Bootloader mode.

3 Problem Analysis

The first thing I suspected was a problem with the USB line. Therefore, when I switched to normal mode (BOOT0=0, BOOT1=0), I used CubeMx to do a simple mouse HID test program to verify it. It turned out that the test program could run normally in normal mode. This shows that there is no problem with the USB line being blocked.

Secondly, check the voltage level of each pin, VDD, BOOT0, BOOT1, and find no abnormality. 
Then open the application document AN2606-STM32 microcontroller system memory boot mode.pdf. From this application document, we can know that different Bootloader versions can be used for firmware upgrade in different ways, as shown in Section 3.2: 

So I wonder if the BID of this MCU does not support DFU? From the above figure, we know that the BID can be read directly through SWD, so we need to find the address that stores this BID information. 
From Table 3 in Section 3.2 of the application document AN2606: 

As shown in the figure above, there are two BIDs in the STM32F2 Bootloader, which can be obtained through the value of the address 0x1FFF77DE. If it is 0x20, it only supports USART. If it is 0x33, it supports USART, CAN, and DFU. So use the PC software STM32 ST-LINK Utility to read the value of the address 0x1FFF77DE through SWD, as shown in the figure below: 

As shown in the figure above, the BID of the STM32F205 used by the customer is 0x33, which supports USART, CAN and DFU at the same time. Therefore, the possibility of a Bootloader version problem is ruled out.

After all the above possibilities were ruled out, the customer suspected that there was a problem with the chip itself or the code burned by the Bootloader, so he found an STM32F4-DISCOVERY board to replace the MCU. The result after the replacement was that the STM32F205 could be normally upgraded through the DFU method of the Bootloader when it was placed on the DISCOVERY board. Therefore, this clearly ruled out the possibility of a problem with the chip itself. Therefore, it could only be a problem with the peripheral circuit of the user's board.

Go back to the application document AN2606 and find the Bootloader workflow diagram in Section 15.2.2, as shown below: 

From the above figure, we can see that the Bootloader checks USART->CAN->DFU in sequence. I wonder if the Bootloader program has entered the USART or CAN mode before DFU for some unknown reason and has not come out?

To rule out this possibility, we pulled up the RX pin PA10 of USART1, the RX pins PB11 and PC11 of USART3, and pulled down the RX pin PB5 of CAN2 for testing. However, the DFU device could not be detected.

Let's go back to the above figure for analysis. As shown in the above figure, if neither USART nor CAN is detected, the Bootloader program will detect whether the USB cable is connected, and then detect the external HSE. If the HSE does not exist, a system reset will be generated, otherwise the system main frequency will be reconfigured to 60M.

Since we are connected to the USB cable and the USB can work normally in normal operation mode, the result of the USB cable detection here should be passed. So according to the program flow, the external HSE is detected next. If the detection fails, the system is reset. Then, the waveform of VDD and NRST pins is checked with an oscilloscope, and it is found that the system is reset 3 times after VDD is powered on. In this way, it can be concluded that the result of the Bootloader program in detecting the external HSE is a failure, as follows: 

Why does the detection of external HSE fail? The HSE used by the user is an 8M crystal oscillator, which is the same as the DISCOVERY board, and is an 8M external crystal oscillator. Compare the user's external crystal oscillator circuit with the corresponding circuit of DISCOVERY, as shown in the following figure: 

As shown in the figure above, the left side is the crystal oscillator circuit of the customer board, and the right side is the crystal oscillator circuit of the DISCOVERY board. By comparison, we can see that the user's load capacitance is 33pF and there is an additional 1M feedback resistor.

First, remove the feedback resistor and test, the result is still the same. Then replace the crystal load capacitor of the customer board with 20pF and test again. The result shows that the DFU device can be detected normally. It can be seen that it is because of this load capacitor that the DFU of the Bootloader cannot work properly!

4 Conclusion

This problem is caused by the crystal oscillator load capacitance being too large, which causes the time point when the built-in Bootloader detects the external HSE to be out of sync with the time required for the actual HSE to stabilize and oscillate. As a result, the HSE cannot be detected, causing a system reset and ultimately making it impossible to use the Bootloader's DFU method to upgrade the firmware.

5 Documents and software download links involved in this article

AN2606 http://www.stmcu.org/document/detail/index/id-200918 
DfuSeDemo http://www.stmcu.org/document/detail/index/id-214339 
STM32 ST-LINK Utility http://www .stmcu.org/document/detail/index/id-215840