Ich habe ein Blackpill-Board mit einem STM32F411CE-U6
Laut "Datenblatt" beträgt der HSE 25MHz
Die maximale Taktfrequenz 84MHz
Ich habe das PlatformIO Beispiel libopencm3-usb-cdcacm geflasht.
Nach meinem Verständnis müsste irgendein USB-Gerät auftauchen. Das ist
leider weder unter Windows 10 noch Ubuntu der Fall.
Das Beispiel ist ursprünglich für ein disco_f407vg.
Daher habe ich in der cdcacm.c
Beim USB-Subsystem muss oft ein Takt von 48MHz anliegen.
Vielleicht mal in der Doku zum Prozessor schauen, welche Timings wo
verwendet werden müssen.
Für meinen STM nehme ich die Cube IDE von STM. Die erzeugt die für den
jeweiligen Prozessor notwendigen Taktungen. Vielleicht damit einmal
rumspielen, und nicht darauf verlassen, dass die Prozessoren gleich
sind.
der F411 rennt mit bis zu 100 MHz, beim F401 sind es 84 MHz.
Für USB muss man das aber auf 96 MHz begrenzen, sonst passt das mit dem
25 MHz clock nicht.
Für 25 MHz ist
PLLM = 25 //1 MHz
PLLN = 192 // 192 MHz
PLLP = 2
PLLQ = 4 // 48 MHz USB
Für dieses Board habe ich ein custom target für Mbed, da gibt es auch
diverse USB Klassen und man braucht nur ein paar Codezeilen für ein USB
Device.
Edit:
die libopencm3 config sollte auch passen, es wird 336 / 7 = 48
eingestellt. Es wird nicht die max. Taktfrequenz benutzt, das ist der
Standardisierung in libopencm3 geschuldet.
Die USB cores können aber unterschiedlich sein, auch innerhalb der STM32
Serien ist nich alles gleich.
Sebastian H. schrieb:> Nach meinem Verständnis müsste irgendein USB-Gerät auftauchen. Das ist> leider weder unter Windows 10 noch Ubuntu der Fall.
Erkennt der Computer denn, dass etwas angesteckt wurde?
Unter Windows bekommst du dann im Gerätemanager ein unbekanntes Gerät
mit gelben Ausrufezeichen. Und er macht ein Geräusch: "di-dong". Unter
Linux sollte der Befehl dmesg etwas ausgeben.
Wenn das nicht der Fall ist, wurde vermutlich der Pull-UP Widerstand am
USB Bus nicht aktiviert. Das würde ich mal als erstes prüfen, da am
einfachsten.
Im Reference Mnaual steht dazu: "As a peripheral, it enables the DP
pull-up resistor to signal full-speed peripheral connections as soon as
VBUS is sensed to be at a valid level (B-session valid)."
Wenn er das nicht tut, könnte die Verbindung zum VBUS Pin gestört sein
oder es liegt ein grober Fehler in der Initialisierungsroutine vor. Die
Taktfrequenz wird erst danach interessant.
Stefan ⛄ F. schrieb:> Erkennt der Computer denn, dass etwas angesteckt wurde?> Unter Windows bekommst du dann im Gerätemanager ein unbekanntes Gerät> mit gelben Ausrufezeichen. Und er macht ein Geräusch: "di-dong". Unter> Linux sollte der Befehl dmesg etwas ausgeben.
Nein es passiert gar nichts. Ich habe inzwischen ein Problem entdeckt
das sich sehr nach dem liest, was ich beobachte.
https://github.com/libopencm3/libopencm3/issues/1119
Scheinbar ist da etwas kaputt, das diese MCU betrifft. Es gibt auch
einen Pullrequest dazu.
https://github.com/libopencm3/libopencm3/pull/1256
Ich werde den zugehörigen Fix mal testen nachdem ich Hardwareprobleme
ausgeschlossen habe.
Danke
Sebastian H. schrieb:> Nein es passiert gar nichts.
Dann wurde der Pull-Up Widerstand an DP nicht aktiviert. Dieser ist die
einzige Voraussetzung dafür, dass "irgend etwas" erkannt wird.
Erst danach versucht der PC eine Kommunikation mit dem Device und meldet
Kommunikationsfehler mit dem charakteristischen "di-dong" Geräusch (bzw.
entsprechenden dmesg Meldungen unter Linux).
Danke.
Laut den USB design guidelines von ST hat die gesamte F4-Familie einen
integrierten Pullup für USB_DP. Ein externer ist daher im
Referenz-Schaltbild nicht vorgesehen.
Der integrierte Pullup scheint auf Grund einer Fehlkonfiguration in
libopencm3's USB-Treibern nicht aktiv zu sein.
Klemmt man die 1k5 zwischen PA12 (USB_DP) und 3.3V funktioniert es
direkt.
Sebastian H. schrieb:> Klemmt man die 1k5 zwischen PA12 (USB_DP) und 3.3V funktioniert es> direkt.
War das nicht ein Generalfehler der Blue Pill und wurde bei der Black
Pill behoben?
Mister A. schrieb:> War das nicht ein Generalfehler der Blue Pill und wurde bei der Black> Pill behoben?
Jein. Die BluePill Board haben einen STM32F103 und der enthält keinen
internen Pull-Up.
Deswegen haben sie einen externen mit falschen 4,7kΩ vorgesehen und noch
falscher mit 10kΩ bestückt. Man sagt ja immer, dass die Chinesen sehr
flexibel seien, aber aus irgendeinem Grund produzieren sie immer noch
mit den falschen 10kΩ Widerständen.
Ich habe es inzwischen per Software behoben.
OTG_FS_GCCFG |= OTG_GCCFG_NOVBUSSENS | OTG_GCCFG_PWRDWN;
OTG_FS_GCCFG &= ~(OTG_GCCFG_VBUSBSEN | OTG_GCCFG_VBUSASEN);
Nachdem libopencm USB initialisiert hat.
Man muss im wesentlichen das VBUS sensing deaktivieren. Sonst wartet die
MCU drauf, dass an VSENS Busspannung erkannt wird, bevor der interne
Pullup aktiviert wird. Also alternativ zum externen Pull-Up hätte es
auch ein high am Sense-Pin PA9 getan.
Der interne Pullup hat natürlich den Charme, dass man das Gerät per
Software verschwinden lassen kann.
Wieder eine Menge gelernt. Danke für die Hinweise
Sebastian H. schrieb:> Der interne Pullup hat natürlich den Charme, dass man das Gerät per> Software verschwinden lassen kann.
Kann man auch bei externem Widerstand: Den Pin als Ausgang konfigurieren
und auf LOW schalten. Ist ein bisschen dirty, geht aber ersatzweise bei
den Controllern, die keinen internen schaltbaren Pull-Up haben.
Sebastian H. schrieb:> Ich habe es inzwischen per Software behoben.>> OTG_FS_GCCFG |= OTG_GCCFG_NOVBUSSENS | OTG_GCCFG_PWRDWN;> OTG_FS_GCCFG &= ~(OTG_GCCFG_VBUSBSEN | OTG_GCCFG_VBUSASEN);>> Nachdem libopencm USB initialisiert hat.
Bitte um detailliertere Angaben, da ich mich auch mit der Nichterkennung
herumschlage, incl. 1k5.
1. in welche Software eintragen
2. Wie initialisiert man libopencm USB
Will gerade die Arduino IDE auf BluePill erweitern, was ohne Probleme
funktioniert. Muss aber die .bin exportieren und mittels ST-programmer
via ST-Link in den BluePill übertragen.
Auch den Bootloader für Version PC13 kann man so flashen.
Ziel ist den BluePill nur in der Arduino-IDE zu flashen. Ich brings zwar
s.o. zusammen, gefällt aber nicht.
Übrigens ist mein ST-Link richtig beschriftet und auf den BluePills sind
Chips mit ST Aufschrift bestückt..
Ich weiss nicht warum du mich persönlich kontaktiert hast, um Hilfe für
dein "permission denied" Problem zu bekommen. Solche Sachen gehören hier
hin, damit andere später auch Nutzen davon haben.
Falls es um Linux geht, hat standardmäßig nur der root User Zugriff auf
USB geräte. Normale User bekommen Zugriff, wenn du den STM32 Cube
Programmer installierst. Dabei werden Dateien in /etc/udev/rules.d
angelegt. Ich habe sie mal angehängt.
> und auf den BluePills sind Chips mit ST Aufschrift bestückt
Was hast du erwartet, dass auf den Fakes ein Totenkopf prangt?
