3
\$\begingroup\$

I have a STM32F401 board and I was able to flash a keyboard firmware successfully via USB DFU by pressing boot0 and pressing/releasing reset buttons available on the board itself. The keyboard firmware works correctly, as show by the dmesg logs below:

[  +7.330366] usb 1-8: new full-speed USB device number 6 using xhci_hcd
[  +0.246888] usb 1-8: New USB device found, idVendor=4454, idProduct=5444, bcdDevice= 0.01
[  +0.000010] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000004] usb 1-8: Product: "Pill60"
[  +0.000003] usb 1-8: Manufacturer: "IktaS"
[  +0.021417] input: "IktaS" "Pill60" Keyboard as /devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-8/1-8:1.0/0003:4454:5444.0007/input/input23
[  +0.055386] input: "IktaS" "Pill60" Mouse as /devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-8/1-8:1.0/0003:4454:5444.0007/input/input24
[  +0.000162] hid-generic 0003:4454:5444.0007: input,hidraw4: USB HID v1.11 Keyboard ["IktaS" "Pill60"] on usb-0000:01:00.0-8/input0
[  +0.006643] hid-generic 0003:4454:5444.0008: hiddev97,hidraw5: USB HID v1.11 Device ["IktaS" "Pill60"] on usb-0000:01:00.0-8/input1

The problem now is that I get errors when entering USB DFU mode. These are the dmesg logs after doing the same procedure stated above to enter DFU mode:

[Sep13 19:06] usb 1-8: USB disconnect, device number 6
[  +0.746053] usb 1-8: new full-speed USB device number 7 using xhci_hcd
[  +0.150048] usb 1-8: device descriptor read/64, error -71
[  +0.230024] usb 1-8: device descriptor read/64, error -71
[  +0.229910] usb 1-8: new full-speed USB device number 8 using xhci_hcd
[  +0.150118] usb 1-8: device descriptor read/64, error -71
[  +0.229960] usb 1-8: device descriptor read/64, error -71
[  +0.106683] usb usb1-port8: attempt power cycle
[  +0.403098] usb 1-8: new full-speed USB device number 9 using xhci_hcd
[  +0.026832] usb 1-8: Device not responding to setup address.
[  +0.233785] usb 1-8: Device not responding to setup address.
[  +0.206127] usb 1-8: device not accepting address 9, error -71
[  +0.123325] usb 1-8: new full-speed USB device number 10 using xhci_hcd
[  +0.026920] usb 1-8: Device not responding to setup address.
[  +0.233615] usb 1-8: Device not responding to setup address.
[  +0.206103] usb 1-8: device not accepting address 10, error -71
[  +0.000156] usb usb1-port8: unable to enumerate USB device

The same messages happen when I plug the board while pressing the boot0 button. Plugging the board this way skips the previously installed firmware and directly goes to the erroneous state.

My understanding is that this board has a bootloader in the ROM that cannot be replaced or modified, so I don't think the flashing of the firmware could have interfered with the bootloader.

Has anyone experienced this problem? Is it possible to fix it?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Which board you have? Where are the schematics to see if there are problems in the design or photos of the built device if there are problems? \$\endgroup\$
    – Justme
    Commented Sep 14, 2021 at 13:59
  • \$\begingroup\$ I've bought from this link on AliExpress: pt.aliexpress.com/item/4000084631884.html, maybe it is pirate? The link doesn't provide a datasheet. Nonetheless, the board worked the first time, and I was hoping it was a dumb mistake that could be reverted. \$\endgroup\$
    – Ian Liu Rodrigues
    Commented Sep 14, 2021 at 15:21
  • \$\begingroup\$ Or the hardware has a design flaw like many of the so called STM32 Blue Pills. If you don't have the schematics or can't reverse engineer the hardware, there's no way to be sure. \$\endgroup\$
    – Justme
    Commented Sep 14, 2021 at 17:21
  • \$\begingroup\$ Given the fact that STM32 mcus are heavily impacted by the current shortage of integrated circuits, I wouldn't be surprised if you had received a poorly working clone. But that's only speculative, could be a hundred other things. \$\endgroup\$
    – nschurando
    Commented Sep 14, 2021 at 17:36
  • \$\begingroup\$ possibly related: STM32F401CCU6 DFU Mode problems? \$\endgroup\$
    – davidcary
    Commented Sep 15, 2021 at 6:49

2 Answers 2

Reset to default
2
\$\begingroup\$

The MCU has two pins, BOOT0 and BOOT1 which select how to boot after a reset. So obviously they both need to be set correctly at reset to go into correct mode. The BOOT0 is a separate pin, but the BOOT1 is shared with one of the GPIO pins, PB2.

The board should not try to enumerate when it is connected to PC while reset button is pushed. If it still tries to enumerate even when pushing the reset button, there may be an external resistor on the USB that is always connected.

Another explanation is that it does enter bootloader properly, but some other interface for firmware upload gets activated due to noise or toggling, so the bootloader deactivates USB before USB connection is detected.

Make sure there are no extra pull-ups on USB data pins, and that there is no pin that floats or has activity when bootloader is entered - all other UART pins must be held static for example.

One more caveat is that when entering the bootloader, for example UART TXD pins of all UARTs that can be used for downloading becomes high outputs, so they must not be driven low by any other circuitry, such as buttons or other logic chips. That might lead to the output pin driving too much current which might cause supply voltage to drop and STM resetting.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Hey, I've got some hints on reddit saying the PB2 pin is internally connected to BOOT1 and that it might be interfering with the boot process. So I've shorted PB2 to GND and did the same DFU dance, and it worked! I will try to understand a little bit better why this works and post an answer. \$\endgroup\$
    – Ian Liu Rodrigues
    Commented Sep 15, 2021 at 1:21
  • \$\begingroup\$ This works because this is the intended way to run bootloader. Read AN2606, section 3.2 "Bootloader activation" \$\endgroup\$
    – Morris
    Commented Sep 15, 2021 at 5:34
0
\$\begingroup\$

I had this exact problem and the solution was to remove all cables from the serial ports. I didn't investigate which one caused the problem.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.