STM32 "black pill" won't enter DFU mode reliably

Question

I'm following the standard process to put an STM32 "black pill" (STM32F401CC) into DFU mode so that I can upload from the Arduino IDE over USB:

1. Hold down boot0.
2. Press and release rst.
3. Release boot0.

When the board is not in a circuit this works somewhat reliably but not 100%. While breadboarding with only a few connections it becomes very unreliable and sometimes won't work at all.

The USB serial device set up by my Arduino sketch works fine, it is only DFU mode that does not want to work.

When it fails to enter DFU mode I see the following error in the Arduino upload process:

      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.13.0                  
      -------------------------------------------------------------------



An error occurred while uploading the sketch
Error: Target device not found
Establishing connection with the device failed

I'm using Arduino on Ubuntu 20.04 and when it fails I see in /var/log/syslog:

Apr 27 13:26:08 smurfenaar kernel: [79594.279257] usb 1-3: USB disconnect, device number 10
Apr 27 13:26:08 smurfenaar kernel: [79595.078232] usb 1-3: new full-speed USB device number 11 using xhci_hcd
Apr 27 13:26:09 smurfenaar kernel: [79595.192387] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79595.413389] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79595.636370] usb 1-3: new full-speed USB device number 12 using xhci_hcd
Apr 27 13:26:09 smurfenaar kernel: [79595.751435] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79595.973367] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79596.082540] usb usb1-port3: attempt power cycle
Apr 27 13:26:10 smurfenaar kernel: [79596.462407] usb 1-3: new full-speed USB device number 13 using xhci_hcd
Apr 27 13:26:10 smurfenaar kernel: [79596.462674] usb 1-3: Device not responding to setup address.
Apr 27 13:26:10 smurfenaar kernel: [79596.666550] usb 1-3: Device not responding to setup address.
Apr 27 13:26:10 smurfenaar kernel: [79596.874414] usb 1-3: device not accepting address 13, error -71

When it is successful I see:

pr 27 13:22:33 smurfenaar kernel: [79379.772197] usb 1-3: new full-speed USB device number 9 using xhci_hcd
Apr 27 13:22:33 smurfenaar kernel: [79379.899601] usb 1-3: New USB device found, idVendor=0483, idProduct=df11, bcdDe
vice=22.00
Apr 27 13:22:33 smurfenaar kernel: [79379.899605] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 27 13:22:33 smurfenaar kernel: [79379.899607] usb 1-3: Product: STM32  BOOTLOADER
Apr 27 13:22:33 smurfenaar kernel: [79379.899609] usb 1-3: Manufacturer: STMicroelectronics
Apr 27 13:22:33 smurfenaar kernel: [79379.899611] usb 1-3: SerialNumber: 3466365E3135

and I can also see it with the lsusb command:

Bus 001 Device 052: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

Answer 1

I found this solution in the stm32duino forums:

Tying A10 to GND successfully makes it enter DFU bootloader mode 100% of the time (though just not leaving PA10 floating is probably sufficient)

Hypothesized Explanation: In the last paragraph of Sec 4.3 of AN2606 (the STM bootloader manual), it states:

It is recommended to keep the RX pins of unused bootloader interfaces (USART_RX, SPI_MOSI, CAN_RX and USB D+/D- lines if present) at a known (low or high) level at the startup of the bootloader (detection phase). Leaving these pins floating during the detection phase might lead to activating unused interfaces.

PA10 is the RX pin for USART_1. I believe that since PA10 is floating, the bootloader senses traffic on USART_1, and believes that's the interface it should use, and thus turns off USB. By tying PA10 to GND, the bootloader doesn't sense UART traffic and correctly enables USB.

While I followed the advice of tying it to ground I assume tying it to ground via a high resistance value would work too and should allow you to keep using PA10 for something else. After tying PA10 to GND I find entering DFU mode is 100% reliable, even when the board is in a circuit.

Answer 2

I recently purchased two "WeAct V3.0 STM32F411" Black Pill boards on eBay. I've purchased many boards & other electronic items from this seller in the past without any issues. This eBay seller is very highly rated: 99.8% positive feedback with >1 million items sold. However, I cannot confirm whether these boards are "genuine" WeAct boards since I did not purchase them directly from WeAct.

Both of my Black Pill boards can be programmed with ST-LINK V2 using the standard 3 (or 4) wire SWD interface pins. No problems.

However, both boards initially failed to enter USB DFU programming mode after resetting boards with the BOOT0 button pressed. Then I tried grounding pin A10 as suggested above. This totally fixed DFU programming. Now both boards program perfectly every time via DFU mode.

The only downside is the requirement to press BOOT0 + NRST buttons on board to initiate DFU programming mode prior to uploading with Arduino IDE.