USB-OTG am STM32: Den Controller als HID oder Massenspeicher nutzen

USB-OTG am STM32 eröffnet Ihnen die Möglichkeit, einen Mikrocontroller nicht nur als „einfaches USB-Gerät“, sondern flexibel als HID (Human Interface Device) oder als Massenspeicher (USB Mass Storage Class, MSC) zu betreiben – und je nach STM32-Serie sogar zwischen Host- und Device-Rolle zu wechseln. In der Praxis bedeutet das: Ihr STM32 kann sich am PC wie eine Tastatur, Maus oder ein Gamepad anmelden, ohne dass Treiber installiert werden müssen, oder als USB-Stick erscheinen, um Logs, Konfigurationsdateien oder Firmware-Updates bereitzustellen. Gerade in Embedded- und Industrieprojekten sind diese USB-Klassen attraktiv, weil sie standardisiert sind und sich in bestehende Arbeitsabläufe integrieren lassen: Konfiguration per Textdatei statt Spezialsoftware, Datenausgabe per Massenspeicher statt proprietärem Protokoll, oder Steuerung per HID statt serieller Schnittstelle. Gleichzeitig bringt USB-OTG typische Herausforderungen mit: Stromversorgung (VBUS), Pull-ups, richtige Taktquellen (48 MHz), Endpoint-Planung, Descriptor-Design und – bei Massenspeicher – ein sauberes Dateisystem sowie Konfliktfreiheit zwischen USB-Zugriff und interner Schreiblogik. Dieser Artikel erklärt die Grundlagen verständlich und führt Sie praxisnah durch Hardware, STM32CubeMX-Konfiguration und typische Fallstricke, damit HID- und MSC-Projekte stabil und veröffentlichungsreif funktionieren.

USB-OTG am STM32: Grundlagen und Begriffe

USB ist ein Host-zentriertes System: Es gibt immer genau einen Host (z. B. PC) und ein oder mehrere Devices (z. B. STM32-Gerät). „OTG“ (On-The-Go) bezeichnet die Fähigkeit, je nach Situation Host oder Device zu sein. Viele STM32 bieten dafür USB-Peripherie in Varianten wie Full Speed (FS) und – in leistungsfähigeren Familien – High Speed (HS, häufig mit externem PHY). Für HID oder Massenspeicher genügt meist Full Speed, sofern die Datenrate moderat bleibt.

• USB Device: STM32 meldet sich am Host als Gerät an (typisch für HID/MSC).
• USB Host: STM32 steuert angeschlossene Geräte (z. B. USB-Stick lesen).
• USB-OTG: Hardware kann zwischen Host/Device wechseln; praktische Nutzung hängt vom Board-Design ab.
• Endpoints: Datenkanäle innerhalb einer USB-Schnittstelle (Control, Interrupt, Bulk, Isochronous).

Für eine kompakte technische Einordnung bietet der Überblick zu USB On-The-Go hilfreiche Grundlagen. Spezifikationsnah, aber gut strukturiert sind zudem die offiziellen USB-Klassendokumente über das USB-IF Dokumentenarchiv.

Welche STM32 eignen sich: USB FS, USB HS und interne vs. externe PHYs

Ob Ihr STM32-Projekt USB-OTG sauber abbilden kann, hängt von der konkreten MCU-Familie und dem Board ab. Viele STM32F0/F1/F3/F4, L0/L4 sowie neuere G- und H-Serien besitzen USB-Funktionalität. Häufige Varianten:

• USB FS Device (integrierter Transceiver): genügt für HID, CDC und MSC in vielen Fällen.
• USB OTG FS: Device und Host möglich, wenn VBUS-Schaltung und ID-Pin-Konzept passen.
• USB HS: höhere Leistung, oft mit externem ULPI-PHY; für HID/MSC meist nur bei hohem Datendurchsatz nötig.

Wichtig ist der 48-MHz-USB-Takt. Viele STM32 erzeugen ihn über PLLs oder spezielle Clock-Generatoren. Ohne stabilen 48-MHz-Takt ist USB-Betrieb unzuverlässig oder scheitert vollständig. Als Referenz für Tools, Middleware und Konfigurationspfade ist die ST-Seite zu STM32CubeMX hilfreich.

Hardware-Basics: D+/D-, VBUS, Pull-ups und ESD-Schutz

USB ist empfindlicher als viele serielle Schnittstellen. Eine solide Hardwareauslegung entscheidet darüber, ob Ihr Device „einfach funktioniert“ oder nur sporadisch enumeriert. Typische Punkte:

• D+ / D- Leitungsführung: möglichst kurz, symmetrisch, als differentielles Paar, mit durchdachtem Return-Path.
• ESD-Schutz: ESD-Schutzdioden nahe am USB-Stecker sind in realen Produkten praktisch Pflicht.
• VBUS (5 V): als Device muss VBUS erkannt werden; als Host muss VBUS bereitgestellt werden (inkl. Strombegrenzung).
• Pull-up: Full-Speed-Devices signalisieren sich über Pull-up an D+ (oft intern integriert, je nach STM32).

OTG-spezifisch: ID-Pin und Stromkonzept

Bei OTG entscheidet der ID-Pin (in klassischen OTG-Designs), ob ein Gerät Host oder Device ist. Viele Entwicklungsboards implementieren OTG nur teilweise oder vereinfachen das Konzept. Prüfen Sie daher vor Projektstart: Ist der ID-Pin beschaltet? Gibt es einen Lastschalter für VBUS? Wird VBUS korrekt gemessen? Ohne diese Details kann „OTG“ in der Praxis auf „nur Device“ hinauslaufen.

USB-Enumerierung verstehen: Descriptoren, Interfaces und Endpoints

Wenn Sie einen STM32 als HID oder Massenspeicher nutzen wollen, ist die USB-Enumerierung zentral: Der Host fragt Descriptoren ab, um Gerät, Konfiguration, Interfaces und Endpoints zu verstehen. Ein typisches USB-Gerät beschreibt:

• Device Descriptor: Hersteller-/Produkt-IDs, USB-Version, Klassenangaben.
• Configuration Descriptor: Energiebedarf, Anzahl Interfaces, Gesamtstruktur.
• Interface Descriptor: Klasse/Subklasse/Protokoll (z. B. HID oder MSC).
• Endpoint Descriptor: Typ (Interrupt/Bulk), Richtung, MaxPacketSize, Intervall.

Für HID ist zusätzlich der HID Report Descriptor entscheidend: Er definiert, welche Reports (z. B. Tastatur-Scancodes, Mausbewegungen, Buttons) übertragen werden. Für Massenspeicher basiert die Kommunikation auf Bulk-Transfers und dem SCSI-Transparent-Command-Set (typisch BOT: Bulk-Only Transport), wobei die genauen Details vom gewählten Stack abhängen.

STM32CubeMX und STM32Cube Middleware: Der typische Projektaufbau

Viele Projekte nutzen den ST-USB-Device-Stack (Cube Middleware). Der Ablauf ist meist:

• USB Peripheral aktivieren: OTG FS/HS oder USB Device je nach MCU.
• USB Device Middleware auswählen: Klasse HID oder MSC (oder Composite, falls unterstützt).
• Clock konfigurieren: sicherstellen, dass 48 MHz für USB stabil bereitstehen.
• NVIC/Interrupts: USB-Interrupt aktivieren, Prioritäten passend zur Applikation setzen.
• Code generieren: Initialisierung und Callback-Struktur übernehmen.

CubeMX erzeugt Grundstruktur, aber bei praxisnahen Produkten sind Anpassungen üblich: Descriptoren (VID/PID, Strings), Report-Descriptor (HID), Speicherbackend (MSC), Cache/Alignment (bei HS und DMA), sowie eine robuste Fehlerbehandlung bei Suspend/Resume oder Kabelabzug.

STM32 als HID: Tastatur, Maus, Gamepad – ohne Treiber

HID ist beliebt, weil nahezu jedes Betriebssystem HID-Geräte nativ unterstützt. Für Embedded-Anwendungen bedeutet das: Sie können Eingaben oder Steuerbefehle an einen PC senden, ohne eigene Treiber oder komplexe Installationsroutinen. Typische Einsatzfälle:

• Tastatur-Emulation: Automatisierte Eingaben, Testsysteme, Produktionsprüfstände.
• Maus/Pointer: einfache UI-Steuerung oder Kalibrierhilfen.
• Gamepad/Joystick: Steuerung von Simulations- oder Bediensoftware über standardisierte HID-Reports.

HID Report Descriptor: Das eigentliche „Protokoll“

Der Report Descriptor definiert Format und Semantik der Daten. Ein häufiger Anfängerfehler ist, zwar HID zu aktivieren, aber den Report Descriptor nicht sauber an die tatsächlichen Daten anzupassen. Dann wird das Gerät zwar erkannt, aber die Eingaben sind „komisch“, unvollständig oder werden gar nicht interpretiert. Gute Praxis ist:

• Minimal starten: z. B. einfache Tastatur oder Maus aus Cube-Beispielen übernehmen.
• Schrittweise erweitern: zusätzliche Buttons/Achsen/Reports hinzufügen und mit Host-Tools validieren.
• Report-Größe beachten: Endpoints haben MaxPacketSize; Reports sollten dazu passen.

Für tieferes Verständnis rund um HID-Descriptoren ist der Einstieg über die HID-Klassenseite des USB-IF sinnvoll, da dort die grundlegenden Dokumente und Referenzen gebündelt sind.

STM32 als USB-Massenspeicher: So wird Ihr Gerät zum „USB-Stick“

Mit der Mass Storage Class (MSC) kann sich Ihr STM32 am Host wie ein Wechseldatenträger anmelden. Das ist extrem praktisch, weil Nutzer Dateien per Drag-and-drop kopieren können. Typische Anwendungsfälle:

• Log-Export: Messwerte, Ereignislogs oder Diagnosedaten als Dateien bereitstellen.
• Konfiguration per Datei: Parameter über eine Text-/JSON-Datei ändern, ohne Spezialsoftware.
• Firmware-Update-Workflows: Update-Datei in ein Verzeichnis kopieren, Gerät verarbeitet sie.

Backend-Speicher und Dateisystem: Flash, SD-Karte oder RAM-Disk

MSC transportiert Blockzugriffe. Ihr Gerät muss also ein Block-Device bereitstellen, typischerweise:

• SD-Karte: sehr verbreitet, gute Kapazität, oft in Kombination mit FATFS.
• Interner Flash: möglich, aber Wear-Leveling und Sektorgrenzen beachten; nicht ideal für häufige Schreibvorgänge.
• RAM-Disk: ideal für Tests, schnell und einfach, aber flüchtig.

In vielen STM32-Projekten kommt FATFS als Dateisystem zum Einsatz. Dabei entsteht ein kritischer Punkt: Wenn der Host (PC) über USB schreibt, und Ihre Firmware gleichzeitig intern auf dasselbe Dateisystem zugreift, drohen Inkonsistenzen. Ein robustes Design trennt daher Zugriffe oder verwendet klare Zustandsmaschinen.

Konflikte vermeiden: Exklusiver Zugriff und „Safe Remove“-Verhalten

Wenn ein STM32 als Massenspeicher dient, sollten Sie die Lebensrealität berücksichtigen: Nutzer ziehen den Stecker, ohne „sicher entfernen“ zu klicken. Um Datenverlust zu reduzieren, helfen folgende Strategien:

• Read-Only-Modus: Gerät stellt Daten nur lesend bereit, interne Firmware schreibt separat.
• Gating: Firmware greift nur auf das Dateisystem zu, wenn USB nicht gemountet ist (und umgekehrt).
• Journaling vermeiden: FAT ist nicht journaling-fähig; konservative Schreibmuster (z. B. Append, Flush) sind sinnvoll.
• Klare UI/LED-Signale: Nutzer erkennen, wann Schreiben läuft und wann Trennen unkritisch ist.

Für Dateisystem-Details ist die Dokumentation von FatFs (ChaN) eine etablierte, praxisnahe Quelle, die in vielen Embedded-Projekten als Referenz dient.

Performance und Stabilität: Endpoint-Typen, Puffer und Interrupt-Prioritäten

HID nutzt typischerweise Interrupt Endpoints (nicht „CPU-Interrupt“, sondern USB-Transfer-Typ), um periodisch kleine Datenmengen zu übertragen. MSC nutzt Bulk Endpoints, die große Datenmengen effizient transportieren, aber nicht garantierte Latenz bieten. Auf STM32-Seite beeinflussen Buffergrößen, Cache-Konfiguration (bei Cortex-M7 besonders wichtig), und Interrupt-Prioritäten maßgeblich die Stabilität.

• HID: kleine Reports, klare Intervalle, geringe Datenrate, sehr zuverlässig bei sauberem Descriptor.
• MSC: größere Transfers, hoher Bedarf an konsistentem Storage-Backend und genügend RAM für Puffer.
• Interrupt-Prioritäten: USB sollte nicht von langen ISRs blockiert werden, sonst drohen Timeouts.

48-MHz-Takt und Clock-Genauigkeit

USB verlangt eine stabile Taktsituation. Abhängig von STM32-Serie gibt es unterschiedliche Wege zum 48-MHz-Takt (PLL, HSI48 mit Trimming, externe Quarze). In industriellen Umgebungen ist ein sauberer Clock-Plan wichtig, insbesondere wenn Temperaturdrift oder EMV den Takt beeinflussen. Prüfen Sie außerdem, ob Ihre MCU ein internes HSI48 mit automatischem Trimming (z. B. über CRS) unterstützt, wenn Sie auf externe Quarze verzichten wollen.

Composite-Geräte: HID und Massenspeicher gleichzeitig

In vielen Produkten ist es attraktiv, mehrere Funktionen in einem Gerät zu kombinieren, etwa „Massenspeicher für Konfigurationsdateien“ plus „HID für Steuerbefehle“. Das nennt man Composite Device. Technisch bedeutet das: Eine USB-Konfiguration enthält mehrere Interfaces (z. B. HID-Interface und MSC-Interface). Das ist möglich, erfordert aber saubere Descriptoren und oft zusätzliche Anpassungen am Stack.

• Vorteil: ein Kabel, mehrere Funktionen, sehr nutzerfreundlich.
• Nachteil: komplexere Descriptoren, mehr Testaufwand auf verschiedenen Betriebssystemen.
• Praxis: zuerst jede Klasse einzeln stabil machen, dann kombinieren.

Debugging in der Praxis: Wenn HID nicht erkannt wird oder MSC „kaputt“ wirkt

USB-Probleme lassen sich meist systematisch eingrenzen. Typische Symptome und schnelle Prüfungen:

• Gerät wird gar nicht erkannt: VBUS fehlt/ungenau, D+/D- vertauscht, falscher USB-Takt, Pull-up nicht aktiv.
• Unbekanntes Gerät: Descriptoren fehlerhaft, falsche Längenangaben, String-Descriptor-Probleme.
• HID erkannt, aber keine Eingaben: Report Descriptor passt nicht, Reports werden nicht periodisch gesendet oder haben falsches Format.
• MSC sichtbar, aber Dateien korrupt: gleichzeitiger Zugriff von Firmware und Host, fehlendes Flush, Stromausfall/Abziehen während Schreibens.
• Transfer langsam: zu kleine Puffer, ungünstige Storage-Latenz (SD-Karte), blockierende Tasks/ISRs.

Hilfreiche Werkzeuge

• USB-Analyse: USB-Deskriptoren und Enumeration mit geeigneten Tools auslesen (betriebssystemabhängig).
• Logic-Analyzer/Oszilloskop: bei physikalischen Problemen (Signalqualität, EMV, Kabellänge).
• Serial/RTT-Logging: Statusmeldungen zu USB-Callbacks, Storage-Operationen und Fehlercodes.

Sicherheits- und Produktaspekte: Identität, Treiberverhalten und Nutzererwartungen

Für veröffentlichungsreife Produkte sollten Sie neben der reinen Funktion auch Produktaspekte berücksichtigen. Bei HID ist die „Treiberfreiheit“ ein Vorteil, aber HID kann in manchen Umgebungen als potenzielles Eingabegerät sicherheitsrelevant sein. Bei MSC ist Nutzerkomfort hoch, aber das Risiko von Dateisystemfehlern bei unsauberem Trennen ebenso. Saubere Kommunikation, klare Statusanzeigen und konservative Schreibstrategien sind hier oft wichtiger als maximale Performance.

• Stabile Identität: konsistente VID/PID (rechtlich/organisatorisch sauber), sinnvolle Produktstrings.
• Kompatibilität: Verhalten auf Windows/macOS/Linux prüfen, insbesondere bei Composite-Geräten.
• Robuste Storage-Logik: klare Zustandsmaschinen, Vermeidung paralleler Schreibzugriffe.
• Dokumentation: Nutzeranleitung für „sicher entfernen“ oder interne Mechanismen, die das Risiko mindern.

Wer sich tiefer in die USB-Klassen einarbeiten möchte, findet im USB-IF Dokumentenportal neben HID auch Spezifikationen zur Mass Storage Class und weitere relevante Dokumente. In Kombination mit den ST-Referenzprojekten und den MCU-spezifischen Reference Manuals erhalten Sie damit eine belastbare Grundlage, um USB-OTG am STM32 als HID oder Massenspeicher praxisnah, stabil und wartbar umzusetzen.

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.