STM32F407 DFU Bootloader geht nicht

Ich denke mal, dass die 25MHz das Problem sind. USB verlangt m.W. 8 bzw. 
16 MHz

VG S.

Das ist es leider nicht, denn im AN2606 (Bootloader App Note) steht beim 
F4xxx folgendes:
"The system clock is derived from the embedded internal high-speed RC 
for USARTx bootloaders. This internal clock is also used for CAN and DFU 
(USB FS Device) but only for the selection phase. An external clock 
multiple of 1MHz (between 4 and 26MHz) is required for CAN and DFU 
bootloader execution after the selection phase."

Sorry, das gilt für den F40x und F41x, nicht allg. für F4xx.

Anderes Kabel probiert? Anderen USB Port? Ich hab da ein paar NXP LPC 
11u35 Dinger herumliegen die sind echt pingelig was das USB Kabel 
anbelangt.

DFU war unter win schon immer etwas problematisch. Es hat ja auch Gründe 
warum es von MS immer noch keinen Treiber dafür gibt und vermutlich auch 
nie geben wird. Falls du das an einem USB 3 Port betreibst schalte Mal 
einen USB 2 Hub dazwischen.

Thomas

Also, ich habe jetzt mehrere Kabel probiert -> kein Erfolg.
Andere USB Buchsen -> kein Erfolg.
USB Hubs (sowohl 2.0 als auch 3.0) -> kein Erfolg.

Dann hab ich es noch an zwei weiteren PCs probiert, auch ohne Erfolg.

Stecke es an einem Linux PC an und schaue dir die Kernel Meldungen an. 
Die geben manchmal hilfreiche Hinweise darauf was da nicht funktioniert.

Nehme auch mal ein USB Beispiel Programm, flashe es auf den Controller 
(per JTAG/SWD) und schaue ob das geht, bzw. prüfe per Debugger warum 
nicht.

Dr. Sommer schrieb:
> Stecke es an einem Linux PC an und schaue dir die Kernel Meldungen an.
> Die geben manchmal hilfreiche Hinweise darauf was da nicht funktioniert.

Gute Idee, das werd ich jetzt dann probieren.

Dr. Sommer schrieb:
> Nehme auch mal ein USB Beispiel Programm, flashe es auf den Controller
> (per JTAG/SWD) und schaue ob das geht, bzw. prüfe per Debugger warum
> nicht.

Das ist interessant. Habe ein Beispiel eingerichtet, bei dem sich der 
Controller als virtueller COM Port ausgibt. Windows erkennt den sofort 
und kann mittels Terminal sogar ohne Probleme kommunizieren.

Tom schrieb:
> Windows erkennt den sofort
> und kann mittels Terminal sogar ohne Probleme kommunizieren.

Na sowas... Mal den Bootloader unter Windows 10 probiert? Sicher dass 
der USB-Bootloader überhaupt startet? Boot-Pins und Option Bytes korrekt 
konfiguriert?

Dr. Sommer schrieb:
> Mal den Bootloader unter Windows 10 probiert?

Hab bisher nur Windows 10 probiert.

Dr. Sommer schrieb:
> Sicher dass
> der USB-Bootloader überhaupt startet?

Ja. Denn den Bootloader startet man immer gleich, indem man den Boot0 
Pin auf 3,3V zieht. Einen Boot1 Pin hat der Controller nicht. Jedenfalls 
(laut AN2606) wählt der Bootloader dann selber die passende 
Schnittstelle aus, da wo er etwas bestimmtes empfängt. Und wie ich 
bereits schrieb, über UART funktionierts. Kann den Controller über UART 
mit dem Tool von ST ohne Probleme flashen.

Für Windows gibt es von Microsoft das Tool USBVIEW. Dies zeigt dir den 
Status und eventuelle Fehler der USB-Schnittstelle an.

Ich hab jetzt hier noch was gefunden: 
https://community.st.com/s/article/FAQ-DFU-mode-with-system-bootloader-is-not-working-while-USB-does

Habe grad leider keinen 8 Mhz Quarz im passender Größe da. Werde mal 
einige besorgen und dann erneut probieren und hier berichten.

Hab doch noch einen 8 Mhz Quarz gefunden und provisorisch angelötet. Und 
es funktionierte sofort. Windows erkennt den Controller als Bootloader. 
Lässt sich einwandfrei programmieren mit dem Tool von ST.

Danke an alle für die Ideen.

Habe zufälligerweise ein ähnliches Problem bei einem STM32F405 mit einem 
16 MHz Quarz. Eine normale USB-Applikation war funktionsfähig, aber 
DFU-Mode nicht. Es stellte sich heraus, dass mit dieser Platine Versuche 
zur Stabilität der Quarzschaltung unternommen wurden und der 
Reihenwiderstand zum Quarz relativ groß war. Nach entsprechender 
Anpassung war DFU-Mode auch mit 16 MHz problemlos erreichbar. (siehe 
auch AN2867 Oscillator design)