ich bin gerade dabei ein Chinaboard 'Devebox STM32XX_M' mit dem H743VI in Betrieb zu nehmen. Mit Mbed das den H743 unterstützt und einen USB Stack hat den ich schon auf verschiedenen F4/F7 laufen habe. Der H743 ist um einiges komplexer, aber die Initialiserung von Clock und USB/PCD wird größtenteils über die HAL gemacht die in Version 1.8.0 enthalten ist. Das Problem scheint am Takt zu liegen, USB1 kann verschiedene Quellen haben: - HSI48 Initialisierung hängt in stm32h7xx_ll_usb.c/USB_CoreReset(). Es wird USBx->GRSTCTL |= USB_OTG_GRSTCTL_CSRST; gesetzt und dann gewartet bis dieses Bit von der HW wieder rückgesetzt wird, das passiert nicht. Google liefert hier Ergebnisse, die Warteschleife ist schlecht programmiert, habe die Wartezeit aber schon bis auf 10s erhöht und es hängt hier trotzdem. Kontrollausgabe auf MCO1 zeigt an das der Takt ca. 48,3 MHz beträgt. Das kann mit CRS korrigiert werden, aber auch hinzufügen von CRS ändert nichts am CoreReset Problem. - PLL1Q gleicher Effekt wie beim HSI. PLL1Q hat den Nachteil das der Sysclock dann max. 192 MHz wird, aber auch mit diesem 'langsamen' Takt hängt die Initialisierung. MCO1 zeigt 48 MHz an. - PLL3Q PLL1 war für 480 MHz Systemtakt programmiert (habe auch langsameren probiert), USB wird mit eigener PLL3 getaktet. Einen MCO für diese Quelle gibt es leider nicht. Mit diesem Takt komme ich aber am weitesten: Init läuft durch, ein USB Gerät wird detektiert, aber es gibt keine Verhandlung mit dem Host und es wird nur Suspend gemeldet (über trace Ausgaben) was nach 3 ms inaktivität auf dem Bus ausgelöst wird. Ich würde da auch den Takt vermuten das dadurch keine gültigen Datenpakete erkannt werden. Hat hier jemand vielleicht einen funktionierenden Code für das Nucleo H743 zum Laufen bekommen? Im Anhang ist die clock config mit zwei Varianten, es wird HSE verwendet, der Quarz hat 25 MHz und USB_DEVICE ist gesetzt.
nach langer Suche habe ich die Ursache finden können. Es hängt mit dem Sleepmode zusammen den MBed als Voreinstellung benutzt. Da sollen die Peripherieinterrupts die CPU wieder aufwecken, und die clocks sind auch als Voreinstellung alle für den Sleepmode aktiviert. Auch für einen externen ULPI, aber unverständlicherweise muss genau dieser deaktiviert werden, sonst wird der Int vom USB nicht gefeuert. Diesen Hinweis habe ich letztendlich im Micropython Forum gefunden, auch da haben sich Leute die Finger wundgesucht. Im Referenzmanual habe ich auch keinen Hinweis darauf gefunden.
Habe ebenfalls so ein Board wo einfach die USB Datenpins zu PIN 21 und 22 vom 743er (TQFP100) verbunden sind. Kann der irgendwie über diese Schnittstelle programmiert/debuggt werden? (SWD adaoter emulationscode im ROM des STM o.Ä.) Oder muss ein externer SWD Adapter her?
Angehängte Dateien:
-
H7-Bootloader.jpg
98 KB
der H7 hat einen Bootloader im ROM und kann per USB, seriell oder SPI programmiert werden. Boot0 auf High Pegel verbinden, USB Kabel anstecken, STM32CubeProgrammer starten und auf USB stellen, connect und fertig.
Johannes S. schrieb: > der H7 hat einen Bootloader im ROM und kann per USB, seriell oder SPI > programmiert werden. FGPA schrieb: > Kann der irgendwie über diese Schnittstelle programmiert/ debuggt werden?
programmieren ja, debuggen nein. Es sei denn man baut sich ein Monitorprogramm was mit dem Debugger kommuniziert. Aber da kenne ich nichts fertiges und SWD ist so einfach zu nutzen und so mächtig das alles andere kaum Sinn macht. Auch die Black Magic Probe kann für den H7 benutzt werden, Dank sehr engagiertem Einsatz von U. Bonnes.
Johannes S. schrieb: > der H7 hat einen Bootloader im ROM und kann per USB, seriell oder > SPI > programmiert werden. > Boot0 auf High Pegel verbinden, USB Kabel anstecken, STM32CubeProgrammer > starten und auf USB stellen, connect und fertig. Super danke, genau dieses Board Johannes S. schrieb: > debuggen nein. Es sei denn man baut sich ein > Monitorprogramm was mit dem Debugger kommuniziert. Aber da kenne ich > nichts fertiges und SWD ist so einfach zu nutzen und so mächtig das > alles andere kaum Sinn macht. Auch die Black Magic Probe kann für den H7 > benutzt werden, Dank sehr engagiertem Einsatz von U. Bonnes. Hmmm habe leider gerade keinen SWD adapter. (Nur ein USB Blaster (JTAG)). Könntest du evtl. etwas genauer beschreiben wie (Black Magic Probe)? Oder funktioniert das alles nicht richtig und wird verschwendete Zeit sein und würdest du mir folglich anraten einfach einen SWD adapter zu bestellen?
BMP gibt es fertig zu kaufen, aber die SW ist auf github frei: https://github.com/blacksphere/blackmagic/wiki Als HW wird ein F103 Board benötigt, sowas sind die STLink Clone oder auch ein Bluepill kann man nehmen. Bei letzterem stört allerdings das da gerade meist keine Original ST µC mehr drauf sind. BMP läuft auch auf einem ESP32 und damit wireless: https://github.com/Ebiroll/esp32_blackmagic Den muss aber erst aktualisieren, für den H7 gab es einige updates in den letzten Monaten. Dann kann man noch die ST Disco oder Nucleo benutzen, da kann man Jumper umstellen und den onboard STLink für externe Boards benutzen. Oder einen Originalen STLink V3, die kosten so ca. 10$ beim Distri. Also es gibt reichlich Möglichkeiten. Nur ob ein USB Blaster auch taugt weiss ich nicht. Im Prinzip müsste es gehen, bei BMP wird auch Bitbanging gemacht. Über OpenOCD geht es eventuell mit dem USB Blaster: https://wiki.cuvoodoo.info/doku.php?id=jtag Aber der H7 ist sehr komplex und da kann die Tücke im Detail stecken.
Aha schade, da habe ich wohl etwas falsch verstanden. Die Idee war, dass über USB direkt das debuggen geht. Zb. indem ich zusatzcode eincompiliere welcher mir die Debug funktionalität gewährt. Also ein wirtueller SWD adapter der auf dem 743er selbst läuft. HW habe ich aktuell einen PIC programmer nen USB Blaster und einen FTDI. (Existiert eine PC Software die den SWD adapter simuliert und das ganze einfach über die GPIOs des FTDIs überträgt?) Wenn ich mich doch für einen SWD adapter entscheiden würde: Welche vorteile hat der Black Magic gegenüber billig SWDs?
FGPA schrieb: >... > einen FTDI. > (Existiert eine PC Software die den SWD adapter simuliert und das ganze > einfach über die GPIOs des FTDIs überträgt?) > Wenn ich mich doch für einen SWD adapter entscheiden würde: Welche > vorteile hat der Black Magic gegenüber billig SWDs? Mit FTDI MSPPE Teilen und einer passenden Kabelbeschreibung kann Blackmagic Hosted ja nach Faehigkeiten des Dongles JTAG oder SWD oder beides. OpenOCD kann auch mit FTDI umgehen, braucht aber auch eine Kabelbeschreibung.
FGPA schrieb: > (Existiert eine PC Software die den SWD adapter simuliert und das ganze > einfach über die GPIOs des FTDIs überträgt?) Über die GPIOs selber nicht. Das benutzt die MPSSE Hardware. Deswegen musst Du Dich an eine ganz bestimmte Pinbelegung halten. Aber es funktioniert. Ich fange langsam an, bei etlichen Projekten den FT2232H einfach direkt mit auf das Systemboard zu packen. Lies das hier: https://www.allaboutcircuits.com/technical-articles/getting-started-with-openocd-using-ft2232h-adapter-for-swd-debugging/ Wenn Du einen grafischen Debugger brauchst: VS Code kann mit dem Cpp-Plugin und den Cortex-M Debug Plugin OpenOCD ansteuern: https://sourceforge.net/projects/openocd/files/openocd/0.10.0/ https://code.visualstudio.com/ https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug fchk
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.