Hallo, seit einiger Zeit versuche ich mich am USB_OTG_FS vom STM32F446R/V/Z. Ich möchte einen normalen Zugang über z.B. ein Terminal haben, und dabei die SPL oder Registerprogrammierung über CMSIS verwenden. Geht aber leider nicht. Der D+ vom USB wird über die 5V Vcc vom USB-Port selbst hochgezogen (1.5k). Das Board ist ein Eigenbau mit 8MHz HSE, wo verschiedene MCU drauf laufen können. Der USB darauf funktioniert mit SPL-OTG-Treibern von ST beim STM32F405, STMF401, STM32F429, STM32F407 und am STM32F103 oder STM32F042 mit unterschiedlichen Treibern (auch mit dem Code von W.S.). Aber nicht beim STM32F446. Verwende ich die HAL und CubeIDE/MX, läuft auch der STM32F446 USB problemlos. Sowohl getaktet über PLLQ (mit SystemCoreclock 168MHz, PLLM 8, PLLN 336, PLLP 2, PLLQ 7) als auch über PLLSAI (SystemCoreclock 180MHz, PLLSAIM 8, PLLSAIN 192, PLLSAIP 4). Im Netz/Datenblatt habe ich gelesen, dass VBUS-sensing abgeschaltet werden soll. Das habe ich nach RM390 in OTG_GCCFG (Offset 0x38) mit Bit21 auch getan. Mit den Registern OTG_GUSBCFG (Offset 0x0C) habe ich experimentiert und Force Device (Bit30) gesetzt sowie HNP_CAP (Bit9) und SRP_CAP (Bit8) abgeschaltet. Außerdem Timings geändert, und die Enumeration testweise über einen GPIO-Pin verzögert. Auch den Trick verwendet, per GPIO PA12 OutputMode den D+ für >50ms auf low zu ziehen, und dann neu enumerieren zu lassen. ->Nichts geht. Irgendwo wird in der HAL etwas richtig gemacht, was in den OTG-Treibern von ST nicht passiert. Hat jemand von euch schon einen STM32F446 mit USB über die SPL am Laufen oder weiss, was da besonders beachtet werden muss?
Uli schrieb: > Irgendwo wird in der HAL etwas richtig gemacht Dann mach es auch mit HAL! SPL ist Schnee von gestern.
Uli schrieb: > Das ist nicht die Lösung für das Problem. Genau das wäre aber die Lösung - aber wenn du das nicht willst, musst du eben weiter frickeln.
Harry L. schrieb: > SPL ist Schnee von gestern. Damit stimmen immerhin die Angaben im STM-Datenblatt. Mit der HAL muß man einen Haufen zusätzliche Doku lesen und es entsteht viel unnützer Overhead-Code. Uli schrieb: > Irgendwo wird in der HAL etwas richtig gemacht, was in > den OTG-Treibern von ST nicht passiert. Ich würde mir alle RCC, PIN, Timer und USB-Register in beiden Varianten in eine Datei umleiten und dann mit einem Difftool nach relevanten Unterschieden suchen. > Hat jemand von euch schon einen STM32F446 mit USB über die SPL am Laufen > oder weiss, was da besonders beachtet werden muss? Ich hab damals (tm) auch nur das Beispiel aus der HAL genommen und für meine Zwecke angepasst. Das funktionierte erstaunlich schnell und problemlos. Was unter der Haube wirklich passiert, davon bekommt man (leider?) nichts mit.
Rick schrieb: > Mit der HAL muß > man einen Haufen zusätzliche Doku lesen Das ist bei jedem komplexen Framework so - keine Arme - keine Kekse. Die Qualität der Dokumentation ist allerdings nach einigen anfänglichen Schwächen inzwischen wirklich sehr gut. Rick schrieb: > es entsteht viel unnützer > Overhead-Code. Ein weit verbreiteter Irrtum, der durch ständiges Wiederholen nicht an Wahrheitsgehalt gewinnt. Rick schrieb: > Was unter der Haube wirklich passiert, davon bekommt man > (leider?) nichts mit. Wer es wissen will, kann in den gut dokumentierten Quellcode schauen und sogar mit dem Debugger durchsteppen. Daran ist nichts Geheimes.
:
Bearbeitet durch User
...was bedeutet denn "nix geht" genauer? STM, CubeMX, HAL, usb-cdc, vcom ist schon ein paar Jahre her aber meine mich zu erinnern zu Erst ging da auch nix (windows pc <-> stm) weil in der HAL ein paar Zeilen code fehlten um auf zwei Parameter zu reagieren, line speed und line noch irgendwas... encoding? Ohne das konnte zumindest windows die Schnittstelle nicht öffnen und somit ging auch nix. Eigentlich total sinnfrei weil die Parameter, zumindest line speed, wohl eh keine Verwendung bei usb-cdc finden. Oder bedeutet "geht nix" es hakt schon viel früher bei evtl. der device enumeration? Versuche doch erstmal weiter einzukreisen an welchem Punkt des ganzen usb-Gedöhns etwas unerwartetes / ein Problem auftritt. Mehr fällt mir dazu auch nicht ein.
Erhälst du überhaupt die Interrutps? Fang mal bei 0 an, kopier die Pin konfiguration von der HAL, überprüfe ob du die Interrupts vom USB erhälst. Kommst du so weit?
Oh, hier tat sich noch was. Sorry für den späten Response. Das Problem ist erstmal beiseite gelegt und ich bin jetzt wieder etwas draussen aus der Materie. Mit "nix geht" war die Enumeration gemeint. Win10 wirft recht zügig den Fehler "unbekanntes Gerät" beim STM32F446. In die Fehlersuche bin ich nicht so weit eingestiegen, dass ich die Interrupts gesucht und verfolgt habe. Es ist etwas ungewöhnlich, dass das USB Programm - geschrieben für den STM32F446 mit 84MHz getaktet - auf dem STM32F401 läuft und auf dem STM32F446 nicht. Das heisst, es liegt auch nicht an der unterschiedlichen, bedingten Kompilierung durch die zahlreichen #if .. #else .. #endif in STM32f4xx.h und anderen systemfiles. Ich kann das hexfile vom STM32F446 einfach auf den STM32F401 spielen und USB läuft. Der 446er muss hardwareseitig eine geringfügig andere USB-Konstellation haben. Ich lese mir später nochmal genauer durch, was ihr geschrieben habt bzw. welche Tests noch machbar sind, und schreibe in den nächsten Tagen dann noch was dazu. Edit: Ein "Diff" zwischen den tatsächlich gesetzen Registern von STM32F446 und STM32F401 habe ich dadurch gemacht, indem ich einfach alle Registerwerte ab 0x5000000 in einen 4k-Buffer (der gesamte USB_OTG-Bereich ist 256k, aber das war mir erstmal zuviel Aufwand) ausgelesen und dann über printf in ein Textfile geschrieben habe. Die beiden Textdateien habe ich zur späteren Analyse gesichert. Problem: Ich weiss nicht mehr, ob ich die Register vor oder nach der - misslungenen - Enumeration ausgelesen habe. An einigen Stellen waren da deutlich unterschiedliche Werte zwischen den beiden MCUs enthalten. Fast zuviele, um das Bit für Bit mit nachzufuchsen. Wie gesagt, mit der HAL geht alles, ohne Tricks, einfach nur mit CubeMX Funktionen definieren und kompilieren; kein Problem. Nur mit der SPL (1.8.1.) tut der STM32F446 als einziger der o.a. MCUs beim USB nicht.
:
Bearbeitet durch User
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.