STM32F105 USB DFU Bootloader enumerates inconsistently

[andrewpellett9]

Posted on August 19, 2010 at 21:01

STM32F105 USB DFU Bootloader enumerates inconsistently

[Nickname12657_O]

Posted on May 17, 2011 at 14:03

Hi anrope,

Does this behavior only on Linux/fedora machine only or also other platforms. Could you please let me know your device trace code and also the Quartz frequency  used on-board ?  More details about Boot-loader selection is

http://www.st.com/stonline/products/literature/an/13801.pdf

( Figure 2, page 15) on our 105/107 devices.

Cheers,

STOne-32.

[Nickname12882_O]

Posted on May 17, 2011 at 14:03

Through further testing, I have found that both boards will consistently enumerate on the 3rd connection. I've verified this on both boards and under windows 7 and fedora 10 (separate hardware).

From reading the bootloader app note, it seems that the 8mhz oscillator is the third configuration to be tried by the bootloader. Is it possible that the bootloader code blocks in a strange way (i.e. waits for some response from the host, instead of timing out) that causes this behavior? Another way to look at this: If I were to use a 14.7456mhz oscillator, would the bootloader work correctly on the 2nd connection?

Please let me know if you have any further insight on this issue. It's really holding me back.

[andrewpellett9]

Posted on May 17, 2011 at 14:03

I have experienced this behavior on fedora (fc10 and fc13, separate boxes) and windows 7.

I currently have two boards populated, and both are experiencing this issue. I'm waiting to build more boards until I can be confident in the bootloader.

The external oscillator (HSE) runs at 8 MHz.

I'm not exactly sure what the trace code is. The markings on the chip are:

(ARM logo) Z

STM32F105

RBT6

991H6 93

MYS 99 011

(ST logo) (E3 circled)

All of my 011 date code STM32F105's share these markings. I also have some pre-937 date code chips that are not useful to me.

Regarding bootloader selection, pins PA10, PD6, and PB5 are tied low on the PCB. There are no connections to any other bootloader interfaces.

[andrewpellett9]

Posted on May 17, 2011 at 14:03

Through further testing, I have found that both boards will consistently enumerate on the 3rd connection. I've verified this on both boards and under windows 7 and fedora 10 (separate hardware).

From reading the bootloader app note, it seems that the 8mhz oscillator is the third configuration to be tried by the bootloader. Is it possible that the bootloader code blocks in a strange way (i.e. waits for some response from the host, instead of timing out) that causes this behavior? Another way to look at this: If I were to use a 14.7456mhz oscillator, would the bootloader work correctly on the 2nd connection?

Please let me know if you have any further insight on this issue. It's really holding me back.

Edit: Somehow the last time I logged in it authenticated me as ''Louis G'' even though I logged in with my own email/password. Something is screwed up.

[sja]

Posted on June 18, 2012 at 19:01

We are now seeing the exact same DFU enumeration inconsistency with ubuntu  10.04 host and the STM32F107 eval board.

Was this problem ever solved ?