Hallo liebe Forumsmitglieder, ich scheitere gerade daran mit einem STM32F103C8T6 eine USB Kommunikation hinzubekommen. Ich versuche einen virtuellen ComPort zu implementieren mit dem dann geloggte Daten ausgelesen werden sollen. Ich habe mich größtenteils an das Beispiel im Forum gehalten. Nur den Pin für das USB Enable Signal (der Pullup an D+) habe ich angepasst. Hardwareseitig gibt es keine Fehler. Die Widerstände haben gemessen die erwarteten Werte, es gibt keine Kurzschlüsse und das Kabel ist eins zu eins mit den entsprechenden Pins des Controllers verbunden. Passieren tut folgendes. Der Controller zieht D+ auf 3,3 Volt (Das wird ja in der USB Init routine gemacht) und erkennt anscheinend das Potential auf der USB Leitung, zumindest wird der USB_Istr() Interrupt ausgelöst. Ab da wird es kritisch weil der Prozessor einfach stehen bleibt. Ich benutze zum debuggen einen Jlink über SWD interface und eclipse. Und wenn ich dann in Eclipse irgendwann auf "Pause" drücke komme ich in ein Fenster wo 0x0 steht. Packe ich in die USB_Istr() einen breakpoint und gehe die routine schritt für schritt mit eclipse durch sehe ich das die USB_Istr() ISR ein paar mal ausgelöst wird. Sobald sie nicht mehr ausgelöst wird kann ich das Programm normal fortsetzen also ohne step debugging. Es funktioniert wie gewohnt (Es wird z.B. jede Sekunde das Display mit der aktuellen Uhrzeit aktualisiert, daran sehe ich auch das es nicht abgestürzt ist). Stecke ich jetzt den USB Port in den USB Hub des Computers, wird wie erwartet die USB_Istr() wieder ausgeführt. Das Programmm kommt zum stehen wenn ich die USB_Istr() nicht im Schritt debug modus einzeln durchgehe. Der Takt des USB sollte passen. Mein Quarz ist 8 MHz, der MCU wird mit 72 MHZ betrieben und der USB Clock divider steht auf 1,5. Da ich die Routine ja im step debug modus durchläuf, gehe ich mal davon aus das ich nicht irgendwo in Speicher schreibe wo ich nicht darf. Kann das eventuell durch Code optimierung hervorgerufen werden? Ich habe eigentlich -O0 als gcc Flag gesetzt. Habe auch schon versucht die NVIC Prioritäten zu ändern um auszuschließen das die ISR irgendwie unterbrochen wird. Die USB ISR hat bei mir jetzt als einzige höchste Priorität. Hat jemand schon einmal ähnliches beobachtet? Grüße, Willem.
Willem B. schrieb: > Hat jemand schon einmal ähnliches beobachtet? Die USB Implementierungen (HAL&co) von ST sind mit großer Vorsicht zu verwenden. Die hat viele Bugs.
Ich habe dieselbe MCU mit dem HAL-CustomHID-Beispiel laufen und musste feststellen, dass sich dort USB und Debugger nicht vertragen. Ob mein Fehlerbild exakt deinem entspricht, weiß ich nicht mehr, da es schon eine Weile her ist. Könnte ich aber heute Abend nochmal ausprobieren. Exakt denselben Code kann ich auf einem STM32L151 problemlos debuggen, aber auf dem F103 springt er irgendwann nicht mehr in die ISR und wird am PC nicht erkannt. Starte ich die ganze Geschichte ohne Debugger, läuft auf Windows-Seite alles problemlos. Im ST-Forum habe ich keine Antwort erhalten. Meine Vermutung ist, dass die USB-Peripherie des F103 alt ist und aus irgendwelchen Gründen im Debug-Modus nicht läuft, weil es Probleme mit dem Timing/Takt gibt. Mein Quarz hat 12Mhz, die CPU 48MHz und der USB-Teiler steht demnach auf 1. Das Problem tritt sowohl mit dem STlink als auch mit der BlackMagicProbe auf.
Hallo, danke für die Antwort. Das habe ich auch schon ausprobiert. Also den Code einfach ohne Debugger laufen lassen. Funktioniert nur leider genau so wenig. Der Controller stürzt einfach ab. Hier im Forum wurde schon einmal das problem beschrieben Beitrag "STM32 USB Virtual COM Port" weiter unten im thread con Lukas M. leider gab es da aber so weit ich lesen konnte keine Lösung. Michael K. schrieb: > Ich habe dieselbe MCU mit dem HAL-CustomHID-Beispiel laufen und musste > feststellen, dass sich dort USB und Debugger nicht vertragen. Ob mein > Fehlerbild exakt deinem entspricht, weiß ich nicht mehr, da es schon > eine Weile her ist. Könnte ich aber heute Abend nochmal ausprobieren.
moin moin, habe auf dem STM32F103C8T6 für USB das HID laufen. Bei der Enumeration sollte das erstmal egal sein. Das Problem beim debuggen ist das enge Zeitfenster von Windows. Habe mir daher Zeichen über die UART ausgeben lassen, da sieht man dann "wo" "was" ist. Prio der ISR habe ich nicht verändert. VG Peter PS:ich progge in Pascal.
Danke, aber ich bin aber noch im Schritt vor der Enumeration. Ich habe auf dem MCU ein funktionierendes Programm und das friert ein wenn ich USB einschalte. Ich glaube ich habe das zu dem Zeitpunkt wo die Interrupts angeschaltet werden eingrenzen können. In verschiedenen Foren gibt es hier ähnliche beispiele, das der controller an der Stelle einfriert aber leider habe ich noch nirgendwo ne Lösung gefunden. Nach etwas weiterem lesen habe ich mich daran erinnert, das durch die ISR irgendwann mal eine Funktion WFI aufgerufen wurde. Ich habe mich noch nie mit STM low power modes beschäftigt, aber wird hierdurch der Prozessor in den Sleep Modus geschickt? Kann es sein das er dort verweilt und aus irgend einem Grund nicht mehr raus kommt z.B. weil ich zu dem Zeitpunkt nur den systick Interrupt laufen habe? Kann es sein das durch step debuging der sleep mode unterbrochen wird, nicht aber wenn Breakpoints ausgeschaltet sind und man dann irgendwie auf pause drückt? Ich lande ja auch nicht explizit im Hardfault handler. Ich werde mal ausprobieren die WFI() funktion nicht aufrufen zu lassen.
Willem B. schrieb: > ich scheitere gerade daran mit einem STM32F103C8T6 eine USB > Kommunikation hinzubekommen. Du kannst einen USB-Treiber im µC NICHT debuggen. Es geht definitiv nicht, da du vom Host nach 3 ms rausgeworfen und auf Eis gelegt wirst. Ich hänge dir mal nen älteren Code hier dran, dn ich vor Jahren für einen STM32F103ZET6 geschrieben habe. Wundere dich nicht darüber, daß er sich am PC als virtueller Nuvoton-COM-Port anmeldet. Es sind 2 Versionen dabei: eine normale und eine Debug-Version. Aber denk nicht mal dran, da mit einem Debugger ranzugehen. Die Debug-Version ist nur für einen in deiner Firmware zu schreibenden Post-Mortem-Debugger gedacht. Siehe "debugfkt.inc". Ich denk mal, daß der C8T6 sich nicht grundlegend vom ZET6 unterscheidet, der Code sollte daher ohne oder zumindest fast ohne Änderungen sofort laufen. OK, den 1k5-Betätiger mußt du in jedem Falle anpassen. W.S.
Hallo, danke nochmal für eure Mühe. @W.S. Das ich nicht die USB Kommunikation debuggen kann ist klar. Ich wollte lediglich feststellen woran es lag. Wie gesagt, gelangte der Chip in einen nicht mehr anzusprechenden Zustand. Trotzdem danke für deinen sehr gut beschriebenen Code. Der ist echt super. Ich habe nun in dem Beispiel der USB ISR Die man hier im Forum unter https://www.mikrocontroller.net/articles/STM32_USB-FS-Device_Lib findet in der Datei usb_istr.c in der funktion void USB_Istr(void) { .... .... if (wIstr & ISTR_SUSP & wInterrupt_Mask) { ---- > Diese Änderung /* this is a hack to disable power suspend */ fSuspendEnabled=0; ---- > Stop Änderung /* check if SUSPEND is possible */ if (fSuspendEnabled) { Suspend(); ..... .... Damit vermeide ich augenscheinlich den USB Suspend. seit dem läuft das Programm weiter und dmesg unter linux sagt : [ 2985.280633] usb 3-3.3: Product: STM32 Virtual COM Port [ 2985.280637] usb 3-3.3: Manufacturer: STMicroelectronics [ 2985.280641] usb 3-3.3: SerialNumber: Pÿlg\xffffffc2\xffffff85SIU'$g [ 2985.308012] cdc_acm 3-3.3:1.0: ttyACM0: USB ACM device [ 2985.308867] usbcore: registered new interface driver cdc_acm [ 2985.308870] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters freu :-) Es lag wohl wirklich daran das der code den chip in den Schlaf geschickt hat.
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.