Problem mit USB auf STM32H743

Gast #6412391
Lesenswert?

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.
Angehängte Dateien:
Gast #6444255
Lesenswert?

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.
Gast #6502866
Lesenswert?

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?
Gast #6502991
Lesenswert?

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.
Gast #6503036
Lesenswert?

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?
Gast #6503060
Lesenswert?

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.
Gast #6503073
Lesenswert?

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?
Gast #6507166
Lesenswert?

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.
#6508305
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren