STM32F446 USB-CDC mit StandardPeripheralLib - nix geht

Uli schrieb:

Irgendwo wird in der HAL etwas richtig gemacht

Dann mach es auch mit HAL! SPL ist Schnee von gestern.

Harry L. schrieb:

SPL ist Schnee von gestern.

Das ist nicht die Lösung für das Problem.

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.

...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.