libopencm USB CDC Gerät nicht erkannt

[Sebastian H. (sebastian_h285)]

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

rcc_clock_setup_pll(&rcc_hse_8mhz_3v3[RCC_CLOCK_3V3_168MHZ]);

durch

rcc_clock_setup_pll(&rcc_hse_25mhz_3v3[RCC_CLOCK_3V3_84MHZ]);

ersetzt und folgende Environment in der platformio.ini verwendet:

[env:genericSTM32F411CE]
platform = ststm32
board = genericSTM32F411CE
framework = libopencm3
debug = stlink
upload_protocol = stlink

Flashen funktioniert. Es passiert USB-technisch aber nichts.

Laut Datenblatt sind die beiden USB-Pins PA11 und PA12.
D.h.

rcc_periph_clock_enable(RCC_GPIOA);
rcc_periph_clock_enable(RCC_OTGFS);

gpio_mode_setup(GPIOA, GPIO_MODE_AF, GPIO_PUPD_NONE, GPIO11 | GPIO12);
gpio_set_af(GPIOA, GPIO_AF10, GPIO11 | GPIO12);

sollte auch passen oder?


Das Blink-Beispiel funktioniert wie erwartet.

Hat da jemand eine Idee?

[PittyJ (Gast)]

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.

[Johannes S. (Gast)]

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.

[Stefan F. (Gast)]

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.

[Sebastian H. (sebastian_h285)]

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

[Stefan F. (Gast)]

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

[Sebastian H. (sebastian_h285)]

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.

[Drago S. (mratix)]

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?

[Stefan F. (Gast)]

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.

[Sebastian H. (sebastian_h285)]

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

[Stefan F. (Gast)]

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.

[Rudi D. (rulixa)]

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

[Stefan F. (Gast)]

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?