2010-08-19 12:01 PM
STM32F105 USB DFU Bootloader enumerates inconsistently
2011-05-17 05:03 AM
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 ( Figure 2, page 15) on our 105/107 devices. Cheers, STOne-32.2011-05-17 05:03 AM
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.2011-05-17 05:03 AM
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.2011-05-17 05:03 AM
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.2012-06-18 10:01 AM
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 ?