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.

[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.

[Josef de Joanelli]

Posted on July 07, 2018 at 01:43

VDD, VDDIO, and VBAT are all connected to a single 3.3V regulator. VDDA is connected to VDD through a ferrite bead. All rails look fine. I have the reset pin connected to a SWD interface connector right next to the chip, plus the recommended 100nF capacitor. That's it.

[waclawek.jan]

Posted on July 08, 2018 at 00:52

Josef,

Sorry, I am out of ideas by now.

You may perhaps observe VDD and DP simultaneously by oscilloscope, and compare what you see there with the Disco board, but honestly I don't know what to expect and how to proceed from there...

JW

[Josef de Joanelli]

Posted on July 09, 2018 at 02:14

Thanks for your help JW. I am out of ideas too!

I probed DP, it looks exactly the same between DISCO and my board. The only difference is on my board, the USB transactions stop after a few seconds when the host gives up trying to enumerate. This information, plus the registers I read out earlier is a pretty solid indicator that the STM is 'booting' into some weird state (not bootloader or application) when the BOOT0 pin is held high. I'm hoping to get some support from ST on this.

Thanks,

Josef

[T J]

Posted on July 09, 2018 at 02:41

it seems you are definately BootLoading..

you should check the BootLoader pin usage chart,

and cross reference those pins to your schematic.

adjust your pinout, ( cut tracks and pull pins High /Low)

it should work...

[Josef de Joanelli]

Posted on July 09, 2018 at 02:56

Hi TJ,

I agree that it should work

I'm not sure what you mean by check bootloader pin usage chart? I'm definitely connected to the correct physical pin because the bootloader behaviour is normal after an external reset. However, assertion of the external reset is not a sustainable solution for us as it goes against our design intentions summarised in the OP.

I've been trying to replicate the issue on my DISCO board, but entry into DFU mode is bulletproof (it's good to know it can be

:)

). Unfortunately, the DISCO board is using the 64pin QFP version (STM32F072RBT6) of my chip (100pin BGA STM32F072V8H6) which is basically the same thing, but I suspect will have some significant silicon differences, at least at the interconnect level, so I'm hesitant to say they should yield the exact same results.

Thanks!

[T J]

Posted on July 09, 2018 at 03:11

I think the 64pin QFP version (STM32F072RBT6) of my chip (100pin BGA STM32F072V8H6) will have the same die..

did you see the AN2606, its a bit old now. STM32 microcontroller system memory boot mode

[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 · Accepted solution]

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.