Hallo, ich habe ein Problem mit dem integrierten Bootloader im STM32F407VET6 (100-Pin LQFP). Über UART funktioniert dieser einwandfrei, aber über USB bekomme ich ihn nicht zum laufen. In Windows erhalte ich immer folgenden Fehler: "Dieses Gerät wurde angehalten, weil es Fehler gemeldet hat. (Code 43) Fehler bei einer Anforderung zum Zurücksetzen des USB-Ports." Im Anhang ist ein Bild von der Beschaltung. Laut Datenblatt vom F407 wird bei DP kein Pullup benötigt. Testweise habe ich es auch mit Pullup probiert, da erscheint allerdings der selbe Fehler. Ebenso habe ich mal die Diodenschaltung sowie die Spule weggelassen, also nur die Widerstände zwischen Buchse und Mikrocontroller, hat aber auch nicht funktioniert (ich habe dafür die Spule sowie Diodenschaltung ausgelötet und stattdessen Lackdrähte eingesetzt um die Kontakte zu verbinden). Die Schaltung nur mit Widerständen wird ja so auch von ST im STLink verwendet. Das ganze befindet sich auf einer selbst erstellten (4-Lagen mit Sig-GND-VCC-Sig) Platine. An den Mikrocontroller ist ein ext. 25 Mhz Quarz angeschlossen. Ich habe mir den HSE Takt mal auf den MCO Pin gelegt und nachgemssen. Es sind saubere 25 Mhz. Im Eratasheet habe ich nichts bzgl USB bzw DFU beim F407 gefunden. Irgendwelche Ideen? Ich weiß nicht mehr weiter :(
Angehängte Dateien:
-
usb_bl.png
7,3 KB
Ich denke mal, dass die 25MHz das Problem sind. USB verlangt m.W. 8 bzw. 16 MHz VG S.
Tom schrieb: > Im Anhang ist ein Bild von der Beschaltung. Laut Datenblatt vom F407 > wird bei DP kein Pullup benötigt. Wenn Code 43 kommt, hat Windows ein eingesteckts USB Gerät erkannt - dafür ist der Pullup gedacht. Tom schrieb: > An den Mikrocontroller ist ein ext. 25 Mhz > Quarz angeschlossen. Mal ins Handbuch geschaut? An den STM32discovery und Nucleos sind IIRC 8MHz Quarze verbaut, was anderes dürfte der Bootloader nicht out-of-the-box unterstützen. Falscher Takt wäre eine mögliche Erklärung für Code 43.
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)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.