STM32 USB HID Keyboard an Win CE

[Lutz K. (Gast)]

Hallo Leute,

ich bin aktuell etwas ratlos und könnte ein paar Denkanstöße gebrauchen.
Es geht um einen STM32F103C8 als USB HID Keyboard. Umgesetzt mit der ST 
Standard Peripheral Library und der ST USB Lib nach 
http://www.dl1dow.de/inhalt/selbstbau/hid_keyboard/index.htm. Am PC 
funktioniert es und ich kann einzelne Zeichen senden. Aber an einem 
Display mit WIN CE drauf funktioniert es nicht. Leider sind dort die 
Möglichkeiten etwas zu überprüfen recht eingeschränkt. Was mir 
aufgefallen ist, am PC mit USB Tree View wird mir der Report Descriptor 
nicht angezeigt. Bei Error steht aber OK. Von meiner echten Tastatur 
wird der Report Descriptor angezeigt. Bei meiner Maus wird er aber auch 
nicht angezeigt. Also keine Ahnung, ob das ein Hinweis sein kann. 
Außerdem steht im USB Tree View noch

----------------- Device Qualifier Descriptor -----------------
Error                    : ERROR_GEN_FAILURE

Hat vielleicht jemand eine Idee in welche Richtung ich noch gucken 
könnte?

[Walter T. (nicolas)]

Lutz K. schrieb:
> T USB Lib nach
> http://www.dl1dow.de/inhalt/selbstbau/hid_keyboard/index.htm. Am PC

Nanu? Wie bist Du auf diesen alten -nicht funktonierenden- Link 
gestoßen? Der aktuelle Link (so seit 2014) lautet: 
http://www.dl1dow.de/artikel/hid_keyboard/index.htm

Zu Deiner Frage: Kann Dein Windows CE-Gerät HID-Geräte mit Full Speed 
adressieren? Im HID-Standard ist das nicht explizit vorgesehen, 
funktioniert unter Windows und Linux trotzdem.


Edit: Ich habe es gefunden. In der _Firmware.txt. Muss ich mal 
korrigieren.

[Lutz K. (Gast)]

Walter T. schrieb:
> Zu Deiner Frage: Kann Dein Windows CE-Gerät HID-Geräte mit Full Speed
> adressieren? Im HID-Standard ist das nicht explizit vorgesehen,
> funktioniert unter Windows und Linux trotzdem.

Hallo Walter,

da hat es ja der richtige gelesen ;-)
Das ist eine gute Frage, ich habe keine Ahnung. Ich dachte es, da meine 
Maus am PC auch als Fullspeed angemeldet ist. Allerdings habe ich auch 
etwas von 2 Geschwindigkeitsprofilen gesehen.
Was müsste ich denn tun, um "low speed" auszuprobieren? Müsste dazu der 
PullUp auch an D-?

[Walter T. (nicolas)]

Lutz K. schrieb:
> da hat es ja der richtige gelesen ;-)

Reiner Zufall. Das Projektchen liegt lange zurück.

Lutz K. schrieb:
> Was müsste ich denn tun, um "low speed" auszuprobieren?

Keine Chance. Der STM32F103 kann meines Wissens nach nur "full speed". 
Deswegen auch diese seltsame Kombination.

[Lutz K. (Gast)]

Walter T. schrieb:
> Keine Chance. Der STM32F103 kann meines Wissens nach nur "full speed".
> Deswegen auch diese seltsame Kombination.

Das wäre aber ärgerlich. Normalerweise geht doch auch immer "langsamer".

Noch eine andere Frage, was hat es eigentlich mit
0x40,                // bMaxPacketSize 64 <===== spaeter: 8
aus
const uint8_t keyboard_DeviceDescriptor[KEYBOARD_SIZ_DEVICE_DESC] =
auf sich? Mit 8 funktioniert es nicht...

[Walter T. (nicolas)]

Lutz K. schrieb:
> Noch eine andere Frage, was hat es eigentlich mit
> 0x40,                // bMaxPacketSize 64

Siehe S. 21:

http://pierrelib.pagesperso-orange.fr/buses/USB_in_a_Nutshell.pdf

Lutz K. schrieb:
> Mit 8 funktioniert es nicht...

Ja, passt dann nicht mehr zu BUFFERSIZE (definiert in keyboard.c).


Alle Tastaturen, von denen ich mir den Descriptor angeschaut habe, 
hatten 8 Bit. Deswegen war das mein ursprüngliches Ziel. Nachdem es 
allerdings an jedem getesteten Rechner mit 64 Bit auch funktioniert hat, 
habe ich es bei 64 Bit belassen, weil dann alle möglichen Telegramme an 
einem Stück hineinpassen und ich mir das lästige Warten erspare.

Ohjeohje....eigentlich sollte man sich so alten Quelltext nicht mehr 
angucken. Und wenn doch, dann jede Urheberschaft abstreiten.

Keine Ahnung, wer meinem Quelltext von vor 5 Jahren verzapft hat.

[Lutz K. (Gast)]

Hehe,

danke für die Antworten.
Mit einem USB-HUB dazwischen funktioniert es. Könnte also wirklich am 
"Full Speed" liegen. Das hilft mir jetzt zumindest temporär etwas 
weiter. Aber wie komme ich nun am einfachsten ohne HUB zu "Low Speed"?

[Rufus Τ. F. (rufus)]

Lutz K. schrieb:
> Aber wie komme ich nun am einfachsten ohne HUB zu "Low Speed"?

Zeig mal den Schaltplan der USB-Anbindung Deines µCs. Gibt es da einen 
Pullup- oder Pulldown-Widerstand an einer der beiden USB-Datenleitungen?

[Stefan F. (Gast)]

> Gibt es da einen Pullup- oder Pulldown-Widerstand an einer
> der beiden USB-Datenleitungen?

Bei dem Stichwort fällt mir ein: Geht es um ein Blue-Pill Board? Da ist 
R10 meistens (immer?) falsch bestückt.

[Dr. Sommer (Gast)]

Lutz K. schrieb:
> Aber wie komme ich nun am einfachsten ohne HUB zu "Low Speed"?

Mit dem Controller gar nicht. Da jeder Host Full Speed können muss, 
macht es für einen Mikrocontroller keinen Sinn, Full Speed und low 
Speed zu unterstützen - verschwendetes Silizium. Daher können die immer 
nur genau eins von diesen beiden. Die Kombination High Speed + Full 
Speed ist allerdings Pflicht, da auch HS Geräte erst als FS starten.

[Rufus Τ. F. (rufus)]

Dr. Sommer schrieb:
> Mit dem Controller gar nicht.

Dann wäre natürlich irgendein AVR mit V-USB eine Alternative. Als HID 
ist das Bit-Banging von dem ja sogar spezifikationskonform.

[Lutz K. (Gast)]

Rufus Τ. F. schrieb:
> Zeig mal den Schaltplan der USB-Anbindung Deines µCs. Gibt es da einen
> Pullup- oder Pulldown-Widerstand an einer der beiden USB-Datenleitungen?

Ich habe einen PullUp an D+ über einen Jumper damit der Host ein Device 
erkennt und ich einfach einen Reconnect durchführen kann. Das 
funktioniert am PC ja auch.

Ist das denn wohl plausibel, dass es am "low speed" liegt, wenn es über 
einen USB-Hub funktioniert? Vielleicht gibt es ja einen "besseren" 
Treiber für das WIN CE Display.

[Rufus Τ. F. (rufus)]

Lutz K. schrieb:
> dass es am "low speed" liegt, wenn es über einen USB-Hub funktioniert?

Der Hub dürfte einen "transaction translator" enthalten und Low-/Full- 
auf High-Speed umsetzen:

https://en.wikipedia.org/wiki/USB_hub#Transaction_translator

[Dr. Sommer (Gast)]

Lutz K. schrieb:
> Ist das denn wohl plausibel, dass es am "low speed" liegt, wenn es über
> einen USB-Hub funktioniert?

Der Hub wird wohl kaum Low Speed am Uplink Port haben?! Der leitet das 
FullSpeed nur durch. Plausibel ist hier aber die Sache mit dem falschen 
Pullup - der PC erkennt ihn gerade noch, das WinCE Gerät nicht.

Rufus Τ. F. schrieb:
> Dann wäre natürlich irgendein AVR mit V-USB eine Alternative

Oder V-USB auf den STM32 portieren.

[Lutz K. (Gast)]

Dr. Sommer schrieb:
> Plausibel ist hier aber die Sache mit dem falschen
> Pullup - der PC erkennt ihn gerade noch, das WinCE Gerät nicht.

Wieso sollte der Pullup falsch sein?

[S. R. (svenska)]

Dr. Sommer schrieb:
> Der Hub wird wohl kaum Low Speed am Uplink Port haben?!
> Der leitet das FullSpeed nur durch.

Aber er spricht auch dann FullSpeed mit dem Host, wenn das Device nur 
LowSpeed kann. Sonst wäre ja eine USB-Tastatur am Hub eine massive 
Bremse...

[Jim M. (turboj)]

Dr. Sommer schrieb:
> macht es für einen Mikrocontroller keinen Sinn, Full Speed und low
> Speed zu unterstützen - verschwendetes Silizium. Daher können die immer
> nur genau eins von diesen beiden.

Das ist so allgemein nicht richtig. NXP LPC11U68 unterstützt z.B. 
beides.

Lutz K. schrieb:
> Ich habe einen PullUp an D+ über einen Jumper

Wie groß ist der Pullup? USB will da 1k5 an 3,3V sehen laut Spec. Wenn 
Du da was anderes genommen hast, könnte das die Fehlerursache sein.

[Lutz K. (Gast)]

Mein Schaltung sieht wie angehängt aus.
Pullup mit 1k5 nach 3,3V an D+. Die 4k7 nach GND habe ich mir auch 
irgendwo abgeguckt. War mir auch nicht ganz sicher ob besser vor oder 
nach der Diode und ob vor oder nach den 22R Serienwiderstand.

[Dr. Sommer (Gast)]

Jim M. schrieb:
> NXP LPC11U68 unterstützt z.B.
> beides.

Ah, weil bei dem Low-Speed ohne Quarz geht, nicht weil man explizit Low 
Speed brauchen würde ;-)

Also in https://www.usb.org/sites/default/files/documents/hid1_11.pdf 
heißt es auf S. 11:

"This specification applies to both high-speed and low-speed HID class 
devices. Each type of device possesses various limitations, as defined 
in Chapter 5 of  the Universal Serial Bus Specification."

Kannst du auf dem WinCE Gerät Wireshark oder gar Linux installieren? 
Beide geben hilfreichere Details aus was da auf dem Bus passiert.

[Lutz K. (Gast)]

Dr. Sommer schrieb:
> Kannst du auf dem WinCE Gerät Wireshark oder gar Linux installieren?
> Beide geben hilfreichere Details aus was da auf dem Bus passiert.

Ich kenne mich damit gar nicht aus. Muss ich probieren. Leider habe ich 
auch so etwas wie den Gerätemanager nicht gefunden. Ich weiß am Display 
quasi gar nichts zum Status.

Ist die Beschaltung mit dem Pullup ok?

[Dr. Sommer (Gast)]

Lutz K. schrieb:
> Ist die Beschaltung mit dem Pullup ok?

Das mit den 1,5 kΩ gegen +3.3V sollte stimmen. Vielleicht sollte man die 
"rechts" von den Serienwiderständen anschließen? Die 4.7kΩ hab ich so 
noch nie gesehen, aber die haben ja keine Wirkung solange der Jumper 
steckt.

C30/C31 finde ich spannend - möchtest du das Datensignal wegfiltern?

Kannst du das USB-Signal am uC oszilloskopieren? Hast du mal eine 
komplett andere USB-Firmware auf den uC geflasht nur um zu sehen ob sie 
am WinCE-Gerät erkannt wird? Kannst du mit einem JTAG-Debugger 
gleichzeitig den Controller durchsteppen und schauen wie weit die 
Enumeration kommt? Da muss man etwas "clever" sein, weil das Anhalten 
des Controllers sofort PC-seitig Timeouts triggert und die Enumeration 
abbricht.

[Lutz K. (Gast)]

Also C30/C31 sind ja optional und nicht bestückt. Hab ich auch irgendwo 
mal gesehen und einfach mal vorgesehen. Kost ja kein Brot.
Den Pullup zwischen USB-Buchse und Serienwiderständen kann ich auch noch 
mal ausprobieren.

Interessanterweise funktioniert es an einem anderen WinCE Display (ganz 
anderer Typ) sogar mit einem älteren WinCE drauf.

Leider laufen keine "normalen" Anwendungen auf dem WinCE. Das macht es 
schwieriger.

Wenn es zu der Beschaltung keine Bedenken gibt, würde ich wohl mal mein 
Glück beim Display Hersteller versuchen. Vielleicht gibt es ja einen 
anderen Treiber oder so...

Wenn es an meiner FW liegt, was könnte dann der HUB bewirken, mit dem es 
ja merkwürdigerweise funktioniert?

Danke für eure Beiträge! Das hat mir schon geholfen.

[Walter T. (nicolas)]

Was motiviert Dich, den Hub unbedingt zu vermeiden?

[Lutz K. (Gast)]

Hm, jetzt hat es tatsächlich mal ohne HUB am Display funktioniert. Aber 
es klappt nicht immer. Gestern hat es nie geklappt.

[Lutz K. (Gast)]

An den einem von 2 USB Ports klappt es meist, wenn der Stecker 
"gefühlvoll" eingesteckt wird. Echt merkwürdig.

Wenn man das mehrfach aufbauen will, dann benötigt man jedesmal 
zusätzlich einen HUB. Das ist doch irgendwie nicht so schön. Außerdem: 
"es muss doch irgendwie gehen" ;-)

[Stefan F. (Gast)]

Ich würde zur Probe mal C30 und C31 entfernen.

[Lutz K. (Gast)]

Stefanus F. schrieb:
> Ich würde zur Probe mal C30 und C31 entfernen.

Die sind doch wie oben schon geschrieben und auch im Plan gekennzeichnet 
gar nicht bestückt!

[Dr. Sommer (Gast)]

Walter T. schrieb:
> Was motiviert Dich, den Hub unbedingt zu vermeiden?

Der Hub weist halt darauf hin, dass da irgendwo ein Problem besteht. Das 
zu ignorieren und immer den Hub zu nutzen ist doch Symptome bekämpfen. 
Irgendwann kommt das Problem dann wieder...

Lutz K. schrieb:
> An den einem von 2 USB Ports klappt es meist, wenn der Stecker
> "gefühlvoll" eingesteckt wird. Echt merkwürdig.

Hmm, vielleicht startet der Controller zu langsam? Wenn du den Stecker 
langsam einsteckst entsteht der Kontakt zu den Datenleitungen "lange" 
nachdem die Spannungsversorgung verbunden ist, und der Controller ist 
bis dahin hochgefahren und kann auf USB-Pakete reagieren. Wenn du 
schnell einsteckst ist die Datenleitung und damit der 1.5kΩ-Widerstand 
"sofort" angeschlossen aber der Controller vielleicht noch nicht bereit 
zum Antworten; dann könnte der PC in einen Timeout laufen. Allerdings 
sollte er es durchaus mehrfach versuchen und Resets senden bis das 
Device antwortet. Vielleicht ist WinCE hier besonders pingelig.

Entferne mal den Jumper, stecke den USB-Stecker (schnell) rein, und 
stöpsele dann erst den Jumper ein. Funktioniert es dann? In dem Fall 
würde es helfen, wenn du den Pullup per Software schalten kannst, und 
zwar erst dann, wenn die Software bereit ist.

[Stefan F. (Gast)]

>> Ich würde zur Probe mal C30 und C31 entfernen.

Lutz K. schrieb:
> Die sind doch wie oben schon geschrieben und auch im Plan gekennzeichnet
> gar nicht bestückt!

Sorry, ich war unaufmerksam.

[Lutz K. (Gast)]

Ohne Jumper die USB Verbindung einstecken und dann den Jumper schließen 
klappt am Display auch nicht. Am PC allerding auch nicht immer.
Am Display sieht es eher so aus, als ob es beim zweiten Mal einstecken 
klappt. Auch mit Jumper. Irgendwie scheint das Display pinkeliger zu 
sein, es scheint aber fast so, als wenn es generell nicht immer klappt. 
Nur am PC eben fast immer.

[Lutz K. (Gast)]

Wieviel Zeit muss man beim Jumper abziehen und wieder einstecken geben?
Wenn ich länger warte klappt es idR zumindest am PC. Manchmal bekomme 
ich aber auch mit 5s Warten mehrfach die Fehlermeldung "unbekanntes 
Gerät". Dann geht es wieder mehrfach. Also irgendwie ist das ganze noch 
zu wackelig.

[Dr. Sommer (Gast)]

Vermutlich prellt der Jumper, sodass man das so nicht vernünftig testen 
kann. Hast du mal verschiedene PCs mit verschiedenen Betriebssystemen 
(Windows, Linux) probiert und vielleicht einen gefunden bei dem es auch 
nicht geht? Dann könnte man da Wireshark installieren...

[Lutz K. (Gast)]

Also der Pullup vor dem Serienwiderstand hat nichts verändert.

Ich kann am "normalen" Windows PC mit Wireshark mal gucken. Da klappt es 
manchmal beim Einstecken ja auch nicht sofort.

[Lutz K. (Gast)]

Also mit Wireshark kann ich nichts finden. Am PC funktionierte es 
zuletzt aber auch zuverlässig. Am Display scheint es reproduzierbar zu 
funktionieren, wenn ich mein Gerät anstecke, es abziehe und wieder 
anstecke. Allerdings auch nur an einem von 2 USB Ports. Am anderen Port 
funktioniert es nur sehr selten.

[Lutz K. (Gast)]

Ich nochmal... es hat mir keine Ruhe gelassen.
Ein kleines Testprojekt mit CubeMX und Standard HID Device (das ist dann 
eine Maus) erstellt und dann umgewandelt in eine Tastatur 
(https://damogranlabs.com/2018/02/stm32-usb-hid-mouse-keyboard) 
funktioniert einwandfrei am Display welches vorher etwas zickig war. Am 
Display (WinCE) kann ich nichts debuggen oder überhaupt etwas zum USB 
Status sehen. Es muss ja einen kleinen aber feinen Unterschied geben. Es 
kommt ja aber nicht nur rein auf die verwendeten Descriptoren an, 
sondern auch auf das Timing. Hat vielleicht noch jemand einen Tipp, wie 
ich den entscheidenden Unterschied meiner beiden Programme bei der USB 
Anmeldung identifizieren kann? Zumindest würde ich damit die HW erst 
einmal ausschließen wollen.

[Lutz K. (Gast)]

Lutz K. schrieb:
> Hat vielleicht noch jemand einen Tipp, wie
> ich den entscheidenden Unterschied meiner beiden Programme bei der USB
> Anmeldung identifizieren kann? Zumindest würde ich damit die HW erst
> einmal ausschließen wollen.

Das ist etwas unglücklich formuliert. Auf Grund des erfolgreichen 
Testprogramms würde ich die HW erst einmal als Fehlerursache 
ausschließen und das Testprogramm als Möglichkeit sehen, den/die 
Unterschied(e) bei der USB Anmeldung zu finden.

[Stefan F. (Gast)]

Lutz K. schrieb:
> Hat vielleicht noch jemand einen Tipp, wie
> ich den entscheidenden Unterschied meiner beiden Programme bei der USB
> Anmeldung identifizieren kann?

Den hast du schon bekommen: Wireshark
Ein besseres Tool dazu kenne ich nicht.

> Auf Grund des erfolgreichen Testprogramms würde ich die HW erst
> einmal als Fehlerursache ausschließen

Ich auch.

[Walter T. (nicolas)]

Lutz K. schrieb:
> Es muss ja einen kleinen aber feinen Unterschied geben

Der wichtigste Unterschied wird sein, daß bei meinem alten Beispiel die 
Standard Peripheral Library Verwendung fand, während beim 
CubeMX-Beispiel der HAL verwendet wird - von der Programmierseite wird 
es Schwierigkeiten geben, überhaupt eine Gemeinsamkeit zu finden.


Wahrscheinlich sind beide Seiten einfach unterschiedlich fehlerbehaftet.

Ich würde jetzt einfach zur funktionierenden Basis wechseln.

[Stefan K. (stefan64)]

Lutz K. schrieb:
> Am Display sieht es eher so aus, als ob es beim zweiten Mal einstecken
> klappt.

Das sieht doch sehr danach aus, als ob es am Startup Timing liegt. 
Entweder sind die Kondensatoren auf Deinem Board schon vorgeladen oder 
das Board geht zwischen dem Ansteckversuchen erst garnicht in den Reset.

Kannst Du mal das Board extern/nicht aus dem USB mit Strom versorgen, 
damit die CPU beim Einstecken bereits läuft?

Gruß, Stefan

[Lutz K. (Gast)]

Stefan K. schrieb:
> Kannst Du mal das Board extern/nicht aus dem USB mit Strom versorgen,
> damit die CPU beim Einstecken bereits läuft?

Hab ich gerade mit der "nicht CubeMX" FW probiert. Board läuft über 
externe Spannung und ich verbinde das USB Kabel... dann klappt es nicht. 
Nur wenn ich das USB Kabel schon eingesteckt habe und dann die Spannung 
anschalte. Aber auch nicht immer.

[Guido Körber (Gast)]

Das Problem beim WinCE ist, dass nie klar ist wie viel USB-Unterstützung 
drin ist. Das kann der Hersteller des Gerätes bei der Konfiguration des 
Systems entscheiden.

Leider gibt es sehr viele Abstufungen, bei denen auch partielle 
Unterstützung der HID-Klasse dabei sein kann.

Möglicherweise verträgt diese WinCE-Version nur Tastaturen mit 
Boot-Report-Format, oder mag es nicht, wenn mehr Usage-Codes definiert 
sind, als ihr aus irgend einem Grund gefallen.

Kurz gesagt: WinCE hat keinen zuverlässigen Support für USB.