STM32F072 DFU Bootloader/Reset Problem

[Josef de Joanelli]

Posted on July 05, 2018 at 08:56

Hi all,

I'm having a strange problem with a design using the STM32F072V8 MCU.

MCU operates at 3.3V. We have a USB connector internal to the product, solely for programming the MCU via DFU.

I have the BOOT0 pin connected to VBUS on a USB connector through a resistor divider that means 3.3V is on the BOOT0 pin whenever USB is connected, and the BOOT0 pin is grounded when no USB is connected.

The intended procedure to access the DFU is to:

- Connect USB to host while device is unpowered

- Power up the device

We expect to enter DFU mode since the BOOT0 pin is held high before the system power is up.

Instead of entering DFU mode, I see the following in Linux dmesg:

[28936069] usb 3-13: new full-speed USB device number 49 using xhci_hcd

[28064068] usb 3-13: device descriptor read/64, error -71

[28300075] usb 3-13: device descriptor read/64, error -71

[28536067] usb 3-13: new full-speed USB device number 50 using xhci_hcd

[28664084] usb 3-13: device descriptor read/64, error -71

[28900059] usb 3-13: device descriptor read/64, error -71

[28008079] usb usb3-port13: attempt power cycle

[28660084] usb 3-13: new full-speed USB device number 51 using xhci_hcd

[28660186] usb 3-13: Device not responding to setup address.

[28868143] usb 3-13: Device not responding to setup address.

[28076066] usb 3-13: device not accepting address 51, error -71

[28204078] usb 3-13: new full-speed USB device number 52 using xhci_hcd

[28204178] usb 3-13: Device not responding to setup address.

[28412188] usb 3-13: Device not responding to setup address.

[28620100] usb 3-13: device not accepting address 52, error -71

[28620142] usb usb3-port13: unable to enumerate USB device

If at this point I then assert the NRST line (by shorting NRST to GND), the MCU resets and the DFU happily comes to life.

I've tried to stretch out the NRST by loading a 1uF capacitor on the NRST pin instead of the prescribed 100nF, but I still see the issue.

I've read some stuff regarding pull-ups on the DP pin of the USB, which I don't have on my design, but the datasheet and the bootloader app note both say I don't need a pull-up. Curiously though, the STM32F072-DISCO discovery board has a DP pull-up installed. I don't see any issues with entering DFU mode on the DISCO board.

Can anyone provide any hints here? I'm kinda running out of things to try.

Thanks in advance!

- Josef

#dfu-bootloader

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[waclawek.jan]

Posted on July 05, 2018 at 11:07

I have the BOOT0 pin connected to VBUS on a USB connector through a resistor divider that means 3.3V is on the BOOT0 pin whenever USB is connected, and the BOOT0 pin is grounded when no USB is connected.

The intended procedure to access the DFU is to:

 - Connect USB to host while device is unpowered

 - Power up the device

I guess the mcu is powered parasitically through the BOOT0 pin enough to start working, switch on the DP pullup causing he host to start enumeration, but the power is not sufficient for subsequent proper working

You are not supposed to pull high a pin of an unpowered device.

JW

[Josef de Joanelli]

Posted on July 06, 2018 at 00:20

I thought this might be an issue too, but I did try manually shorting the BOOT0 pin to the MCUs VCC, and without USB plugged in. I power up and then plug USB in and see the same issue.

I saw some errata for the stm32f070 series that suggested there were some issues with the bootloader firmware for that series, is it possible I'm experiencing the same issues?

[waclawek.jan]

Posted on July 06, 2018 at 01:05

Then I don't know.

Can't the problem be related to the bootloader falsely entering one of the other modes, due to 'activity' on some of the 'sensitive' pins (e.g. USART1_RX/USART2_RX) upon powerup, caused by some attached circuitry?

JW

[waclawek.jan]

Posted on July 05, 2018 at 11:12

Curiously though, the STM32F072-DISCO discovery board has a DP pull-up installed.

I don't see any DP pullup on the STM32F072-DISCO's schematic in UM1690 (except of the STLink's pullup, R8, switched by a transistor; but that's a different mcu, a 'F103).

[Josef de Joanelli]

Posted on July 06, 2018 at 00:16

Ah yes, my mistake, you are correct.

[Josef de Joanelli]

Posted on July 06, 2018 at 06:35

Some further information.

I've hooked up an STLink to my design to read out some registers while supposedly in bootloader mode (as in the state where it's not working correctly).

• 0x40010000 is all zeros indicating that System Memory is not selected, which will obviously be a problem since that's where the bootloader code sits...

Further:

• 0x40021034 indicates that the HSI48 is disabled, which means no clock config has been done.
• All USB peripheral registers from 0x40005C00 onwards, all are set to zero so no USB config has been done.

So for some reason the MCU is not correctly detecting the BOOT0 pin?

[Jan Waclawek]

Posted on July 06, 2018 at 07:55

Bad solder joint on that pin?

JW

[Josef de Joanelli]

Posted on July 07, 2018 at 01:36

We see the same behaviour on all boards, so I think it's pretty safe to eliminate manufacturing issues.

[aclex]

Sorry if I'm a little late, but maybe this would help someone coming across here with the same problem.

I experienced exactly the same behaviour due to soldering problem on my PCB: it turned out, that DM was soldered improperly (no connection at all), while the rest of the interface was fine. So the host system used to print the same bunch of messages and the port became disabled after several tries. Right after I re-soldered DM pin, it started working fine.

[Josef de Joanelli]

So, I solved the issue a few months ago but have been off work since then.

In my case, I had a flash memory attached to USART1 (or 2, can't remember, but doesn't matter) and another external part accessing the flash during power up. The STM32 is there to load a binary onto the flash during production and would tristate the USART pins during runtime.

Because there was activity (from the other system device trying to access the flash) on the USART pins when BOOT0 was asserted, the STM32 entered it's UART bootloader flow and thus the USB core was never initialised.

The reason the bootloader worked over USB after reseting the STM32 (without interrupting power) was that the external device was no longer accessing the flash after a couple of seconds after power up, so the desired USB boot flow was able to be entered.

Asserting the external device's reset in hardware made sure it never tried to access the flash device until we entered runtime.