31-USB_CDC-Library (STM32F4)

Hier eine Library um den USB-OTG-Port am Discovery-Board im CDC-Mode zu betreiben. Damit wird beim Verbinden mit einem PC ein virtueller Comport eingerichtet über den man (wie per UART) Daten austauschen kann.

Auf der PC Seite muss der “VirtualComPort-Driver von ST” installiert sein. Den gibts auf der ST-Seite zum download (ich hab mit Version 1.3.1 getestet).
Auf der ST-Seite nach “STSW-STM32102″ suchen.

Die LIB erwartet beim empfang als Endekennung das Zeichen “0x0D” = CarriageReturn
(das muss der PC also am Stringende anhängen)

Beim Protokoll (Baudrate, Stopbits usw) muss nichts eingestellt werden, das wird vom USB-Treiber erledigt. Bei einer Geschwindigkeitsmessung für das senden von einem Block von 1024 Bytes vom PC zur CPU bin ich auf ca. 4ms gekommen, was ca. 256kByte/sec entspricht (ca. 2Mbit/sec)…ob das aber durchgehend eingehalten wird, kann ich nicht sagen.
(Nachtrag : im Capture-Tool-Projekt komme ich auf Datenraten von ca. 7MBit/sec, wobei USB-FullSpeed mit max 12MBit/sec spezifiziert ist)

In der Library gibt es eine Sende und eine Empfangsfunktion für Strings und eine Funktion zum testen ob die USB-Verbindung steht.

Ich hab auch ein “mini” PC-Terminal-Programm geschrieben um die Funktion zu testen.

Es wird ein USB-Kabel mit Micro-USB-Stecker benötigt. (gibts bei EBay oder Amazon)

Benutzte Pins

  PA8   -> USB_OTG_SOF (wird nicht benutzt)
  PA10  -> USB_OTG_ID
  PA11  -> USB_OTG_DM
  PA12  -> USB_OTG_DP

Voraussetzungen :

Benutzte Module der CooCox-IDE : GPIO, MISC
Benutzte Librarys : keine

Enumerationen :

typedef enum {
  USB_CDC_NO_INIT =0, // USB-Schnittstelle noch nicht initialisiert
  USB_CDC_DETACHED,   // USB-Verbindung getrennt
  USB_CDC_CONNECTED   // USB-Verbindung hergestellt


typedef enum {
  NONE = 0,  // keine Endekennung
  LFCR,      // LineFeed + CarriageReturn (0x0A,0x0D)
  CRLF,      // CarriageReturn + LineFeed (0x0D,0x0A)
  LF,        // nur LineFeed (0x0A)
  CR         // nur CarriageReturn (0x0D)


typedef enum {
  RX_USB_ERR =0, // keine USB Verbindung
  RX_EMPTY,      // nichts empfangen
  RX_READY       // es steht was im Empfangspuffer

Funktionen :

void UB_USB_CDC_Init(void);                                                // zum init der USB-Schnittstelle
USB_CDC_STATUS_t UB_USB_CDC_GetStatus(void);                               // USB Status abprüfen
ErrorStatus UB_USB_CDC_SendString(char *ptr, USB_CDC_LASTBYTE_t end_cmd);  // zum senden eines Strings per USB
USB_CDC_RXSTATUS_t UB_USB_CDC_ReceiveString(char *ptr);                    // zum empfangen eines Strings per USB

Beispiel :

// File     : main.c
// Datum    : 07.04.2013
// Version  : 1.0
// Autor    : UB
// EMail    : mc-4u(@)t-online.de
// Web      : www.mikrocontroller-4u.de
// CPU      : STM32F4
// IDE      : CooCox CoIDE 1.7.0
// Funktion : Demo der USB-CDC-Library
// Hinweis  : Diese zwei Files muessen auf 8MHz stehen
//              "cmsis_boot/stm32f4xx.h"
//              "cmsis_boot/system_stm32f4xx.c"
#include "main.h"
#include "stm32_ub_usb_cdc.h"
int main(void)
  char buf[APP_TX_BUF_SIZE]; // puffer fuer Datenempfang
  SystemInit(); // Quarz Einstellungen aktivieren
  // Init vom USB-OTG-Port als CDC-Device
  // (Virtueller-ComPort)
    // Test ob USB-Verbindung zum PC besteht
    if(UB_USB_CDC_GetStatus()==USB_CDC_CONNECTED) {
      // Ceck ob Daten per USB empfangen wurden
      if(check==RX_READY) {
        // wenn Daten empfangen wurden
        // als Echo wieder zurücksenden
        // (mit LineFeed+CarriageReturn)

Hier die Library zum Download :


Hier der komplette CooCox-Projektordner zum Download :


Hier der Link zu dem PC-Programm :


71 Antworten auf 31-USB_CDC-Library (STM32F4)

  1. Dmitriy sagt:

    Hi. Thanks for you tutorials.
    i have some problems.

    first problem – i can use your terminal to comunicate with device, but i cant communicante with other terminals. Nothing is returning. i used string such as TEST0x0D

    Second problem. when i send string about 20 times – stm32f4 goes crasy and send some string all time. string looks like “*P[Z! F@`W:BO!(F[(y@tr@}{“BZr-9pzQ2ol”


    • admin_ub sagt:

      your terminal must send a “CarriageReturn” at the end of the string, instead of the characters “0x0D”. So when you try to send “TEST” the terminal must send 5 Bytes : 0×54, 0×45, 0×53, 0×54, 0x0D

      To verify the second problem i need your complete Projekt (main.c). please send it to me as zip-file.

      • Dmitriy sagt:

        I have second problem on you code as is. with absolutelly no changes. and use your terminal with word “HELP”.
        send 20 times and have infine loop with strange string comes all the time.

        • admin_ub sagt:

          uhh..ok, i will check this here, hang on.

        • admin_ub sagt:

          ok, i have here the same problem !!
          I will check this and give a feedback, thanks for comment :-)

        • admin_ub sagt:

          BUG is now fixed, Version 1.2 is online, please test it again.

          • STler sagt:

            Have you updated the Terminal in Version 1.2?
            My download today is version 1.0

            Thanks and best regards!

          • admin_ub sagt:

            the actual Version of the Terminal_Program is 1.0 and the STM-Library has Version 1.4 (there was no need to update the Terminal because the BUG was in the STM-Library)

  2. lungfish sagt:

    Hi there!
    First of all – thanks for sharing your code with the world.

    I just downloaded ub_stm32f4_usb_cdc_v102 and compiled it in Coocox 1.7.

    My device uses a STM32F407VG, HSE is 8MHz. The USB-FS connection is device only, e.g. PA8-SOF and PA10-ID are not connected.
    DFU with DFUSE works like a charm.

    Problem with your project: My Win7 doesn’t even register a new USB device.
    When crawling through the code I asked myself, if it’s correct to use PA9-VBUS as output (thus never seeing the connection status).

    Looking forward to your reply, lungfish

    • lungfish sagt:

      I withdraw the part about PA9-VBUS being an output. Sorry.
      Still trying to get the example running, though.

      • admin_ub sagt:

        SOF (PA8) is not used but i am not sure about the ID-Pin (PA10) …try to connect it to GND. Have you installed the right VCP-Driver from STM ?

        • lungfish sagt:

          Sooo – I should have quit earlier, yesterday.
          Anyways – I took an Olimex STM32-E407, changed its HSE to 8MHz and
          – your example works without any mods.
          Now that I have a baseline to start from, I’ll go back to my board and we’ll see.

          • lungfish sagt:

            The ID-Pin can be left open, even the internal PullUp is OK.

            Soo – for safety reasons I had a 1k resistor between PA9 and VBUS.
            Change that to 22R and the show is on the road.
            Now the unpowered device sucks power from the PC, though.

          • admin_ub sagt:

            Nice. On the STM-Discovery-Board there isn’t a resistor anywhere. PA9 is directly routed to the USB VBUS Pin.

  3. lungfish sagt:

    Without the resistor, the unpowered board sucks power through the internal PA9 protection diode.
    I’ll have to think about a solution for that. Could kill the STM32 under the wrong circumstances.

  4. Malte sagt:


    thanks for sharing your librarys.

    How fast is this CDC Library? I need to transmit every 20ms a maximum of 1024 byte in approx 5 ms (something about 1.6MBit). So, no continous stream. In a short time quite a few data.
    I think isochronous transfer would be the best. But i want to avoid this cause i havent found any good example for this (i think i would have to write Win and Linux driver on my own).
    Or do anyone found examples USB isochronous with win+linux driver + demoapplication (never wrote a program for linux or win)

    • admin_ub sagt:

      I don’t know the speed of the USB-Transfer, but i can check this. I think the bottleneck is on the PC-Side, with the “normal” Terminal settings you can get 115200 Baud wich is too slow. It is not a easy problem with no experience :-)

      • Malte sagt:


        thanks for your fast reply. I found this:
        But, as i understand, thats bulk mode which is for high data rates, but not for time critical processes. But i need to transfer my “process image” every 20 ms
        But, maybe i give it a try.

        Maybe using hterm? Or linux.

        USB or writing a OS driver… till now uart was always suitable for my projects…

        • admin_ub sagt:

          now i checked the speed with a terminal program (in a quick and dirty test) . For a block of 1024 Bytes (plus one end character) i measured a time between 3 and 4 ms. So this is in your limit. But i dont know what happend by repeating this every 20ms…it’s on you to test this :-) To do this with my Library you have to change the size of the Receive Buffer (File=usbd_cdc_vcp.h) …use this :
          #define APP_TX_BUF_SIZE 2048

  5. Malte sagt:

    Thanks for you test. I will try to setup a linux OS an fire all 20ms a given load. I will read the data and compare it.
    Again, thanks for the test!

  6. Peter sagt:

    danke für das Demo!
    Ich verwende ein STM32F4-Discovery und Win7 x64 mit dem ST Treiber 1.3.1. Alles funktioniert bestens.
    Wenn man allerdings bei einer geöffneten Verbindung (z.B. Open in deinem Terminal) einen Reset auf dem Discovery auslöst, ist der PC ‘beleidigt’. Der Gerätemanager zeigt zwar beim Loslassen des Resettasters wieder einen COM Port an, man bekommt aber keine Verbindung. Egal ob Close+Open oder Neustart des Terminals. Erst nach dem Schließen des Terminals, einem Reset am Discovery und einem Neustart des Terminals funktioniert der Open wieder.
    Kennt jemand eine Lösung für dieses Problem?

    • admin_ub sagt:

      ja, mein Terminal Programm ist “Quick&Dirty” such einfach ein anderes PC-Programm mit Fehlerbehandlung :-)

      • Peter sagt:

        Mit Hyperterminal und ZOC habe ich das gleiche Problem. Schaut aus als wäre es ein Treiberproblem. Eine Fehlerbehandlung auf dem PC reicht wahrscheinlich nicht aus, da man das Discaovery zusätzlich reseten muss.
        Bin weiterhin für Ideen und Tips dankbar.

  7. Peter sagt:

    Hier noch ein Hinweis.
    Die ST USB OTG Library hat einen bug, der bei dir evtl. noch nicht abgefangen wurde (google mal nach ep->xfer_count). Bei mir wurden Unmengen an USB Interrupts ausgelöst. Wenn du in usb_dcd_int.c nach Zeile 468 folgende vier Codezeilen einfügst sollte das Problem beseitigt sein:

    if( ep->xfer_count >= ep->xfer_len) {
    uint32_t fifoemptymsk = 1 < < ep->num;
    USB_OTG_MODIFY_REG32(&pdev->regs.DREGS->DIEPEMPMSK, fifoemptymsk, 0);

  8. Martin sagt:


    zunächst vielen Dank für die Veröffentlichung deiner erarbeiteten Sachen, sie haben mir schon oft geholfen. Ich arbeite mit dem STM32F4Discovery auf Grund einer Studienarbeit. Dank der STM32F4xx_DSP_StdPeriph_Lib habe ich es auch hinbekommen die ganze Beispiele selbstständig nachzuvollziehen und zum Laufen zu bringen etc. Also USART, CAN und so.
    Als nächstes benötige ich USB, deine Beispiele funktionieren wunderbar, ich hab jedoch das Problem, dass ich diese nicht einfach verwenden kann, ohne den Weg dahin zu wissen, daher habe ich versucht, ähnlich wie bei USART und CAN, dies über die STM32_USB-Host-Device_Lib zu implementieren. Es hagelt aber massenweise Fehler und ich weiß nicht, wo ich anfangen soll die Lib von STM anzupassen.

    Hast du irgend einen Tipp oder irgend eine Beschreibung, die die USB Lib besser erklärt, oder wie du vorgegangen bist? Ich brauch irgendwie n Anstoß.

    Danke schonmal und weiter so!

    • admin_ub sagt:

      Hi, bei STM gibts beim “STM32F107RB” unter “Design Resources” Links auf viele Bibliotheken u.a. bei “STSW-STM32046″ eine USB-Lib da ist ein Beipspiel für USB-VCP dabei…das habe ich als Basis benutzt.

      • Martin sagt:


        solangsam steig ich bei der Library halbwegs durch.

        Habe aber noch eine Erklärfrage.

        Weißt du, wo die Funktion “static uint16_t VCP_DataRx (uint8_t* Buf, uint32_t Len)” aufgerufen wird. Dein Kommentar im Quelltext lautet dazu “Wird beim Empfang von einem Zeichen aufgerufen”.
        Im gesamten Quellcode finde ich jedoch kein Aufruf der Funktion. Ich hatte vermutet, dies geschieht per Interrupt oder ähnlichem, habe jedoch nichts gefunden.

  9. admin_ub sagt:

    uhh, sorry , k.A. das ganze USB-Thema ist sehr Umfangreich und ohne die fertigen Sourcen von ST wäre ich da nie auf einen grünen Zweig gekommen. Ich würde mal Braikpoints im File “usbd_cdc_core.c” setzen (da sind die DataIn/Out-Funktionen) und schauen wann die zuschlagen.

  10. Martin sagt:


    ich nutze Ihre USB Bibliothek.
    Bei der Übertragung PC -> Mikrocontroller komme ich je nach System auf Geschwindigkeiten > 200 kB/s oder gar > 300 kB/s, je nach PC System.

    Ich bin jedoch überrascht, dass die umgekehrte Richtung wesentlich langsamer ist ca. 110 kB/s . Mein STM32 macht nichts anderes als in der while(1) Schleife die Funktion UB_VCP_DataTx(65); auszuführen. Ich mess das ganze mit HTerm, da dort die Anzahl der Bytes und die vergangene Zeit angezeigt werden kann.

    Ich frage mich, ob und wie diese Geschwindigkeit verbessert werden könnte? Für Ideen oder Hinweise wäre ich sehr dankbar.

    Beste Grüße

    • admin_ub sagt:

      Sind das 110 kBit/s oder 110kByte/s ? Bei der CDC-LIB wird im Bulk-Mode gesendet und zwar immer 64 Bytes. Vielleicht ist der Puffer nicht ganz voll und es werden Datenbytes “verschenkt” … hab da aber keine große Ahnung von :-( Event. mal mit der Puffergröße spielen oder schauen wie weit der Puffer voll ist.

  11. andrew sagt:

    Hellow, please help me.
    .\usb5.axf: Error: L6200E: Symbol USB_CDC_STATUS multiply defined (by stm32_ub_usb_cdc.o and main.o).
    .\usb5.axf: Error: L6200E: Symbol USB_CDC_STATUS multiply defined (by usbd_cdc_vcp.o and main.o).
    .\usb5.axf: Error: L6200E: Symbol USB_CDC_STATUS multiply defined (by usbd_usr.o and main.o).

    • admin_ub sagt:

      do you have modify the “demo_31-Projekt” ? looks like you have defined a second variable with the name “USB_CDC_STATUS” in your code.

      • andrew sagt:

        I ran your code without changes

      • andrew sagt:

        I do not use “demo-31-project” because it’s my compiler KEIL

        • admin_ub sagt:

          ok, try this :
          1. move this complete line :
          from the file “stm32_ub_usb_cdc.h” to the file “stm32_ub_usb_cdc.c”
          (insert it beneath the include lines)
          2. open the file “usbd_usr.c” and insert this line :
          extern USB_CDC_STATUS_t USB_CDC_STATUS;
          (insert it beneath the include lines)

          and give a reply

          • andrew sagt:

            Thank you very much for your help! The project successfully assembled! Unfortunately, my computer still does not recognize my device (STM32F4DISCOVERY), it says unknown device. And WinDriver it also does not see, that is, Virtual COM ports are not created.

          • andrew sagt:

            Спасибо за вашу помощь, я написал правильные настройки скорости и всё теперь работает!!!

  12. malte sagt:


    ich habe folgendes Problem, nutze allerdings das Projekt “Show 01″. Ich will einen Datensatz mit 4×64 byte an den STM übertragen. 64 Byte, da das ja die maximale Bytegröße für den Bulktransfer ist. Ich checke also nun in der while – schleife ob etwas im Buffer ist. Als Rückgabewert bekomme ich ja die Anzahl der Bytes.
    Nun ist es so, das ich am PC immer 64 Byte kurz hintereinander verschicke, der STM aber denkt es wären z.B. 128. Wäre ja nicht schlimm, wären es eben 2 Pakete. Dumm ist aber nur, das die ersten 64 Byte richtig sind, dann kommen vielleicht 30 Byte Müll und die letzten Byte sind wieder richtig.
    Ein weiteres Problem ist, das ist kein festes Endezeichen habe, sondern mir wurde ein Frame so definiert:
    0×01 0×02 Daten 0×04 (Gesamtbreite 64 Byte). Jedes Datenbyte kann 0×00 oder oxFF sein, also keine Asciicodierung. Vielleicht muss ich einfach mal die USB CDC Library abspecken (Endeerkennung raus und selbst parsen). Aber ich sehe halt noch das Problem mit den “Mülldaten”. Hat hier jemand eine Idee?

    • admin_ub sagt:

      ich kann mir nicht vorstellen das “müll” übertragen wird. Entweder läuft ein Puffer voll oder du hast irgendwo anders ein Problem. Ich hab die Lib eigentlich zum Übertragen von Strings geschrieben. Datenwerte kleiner 32dez werden rausgefiltert. Wenn du keine Endekennung hast und alle Bytewerte nutzen willst, musst du selber eine Empfangsfunktion schreiben.

      • Malte sagt:

        Die Filterung “Ascii” hab ich rausgeworfen. Dann muss ich mal weiter forschen wo da der Fehler liegt. Eine einfache Vergrößerung des Eingangspuffers von 64 z.B. auf 128 geht ja nicht, weil Windows dann den STM CDC nicht mehr erkennt.
        Am liebsten wäre mir quasi wie in der guten AVR Welt ein Empfangsinterrupt, wo jedes mal ein Byte raushüpft. Dann könnte ich meinen Standardparser nutzen. Alte Zeiten…

        • admin_ub sagt:

          die Puffer größe wird im File “usbd_cdc_vcp.h” eingestellt mit dem Define “APP_TX_BUF_SIZE” stell den mal auf 2048 und schau was passiert.

  13. Robert sagt:

    Kann die library auch für andere controller angepasst werden?
    z.b freescale kl25xx?

    • admin_ub sagt:

      falls die CPU einen USB-Port hat natürlich, es ist doch der komplette Quellcode in “c” vorhanden. Allerdings muss das jemand anders machen, ich hab mich auf den STM32F4 eingeschossen.

  14. Opcode sagt:

    Guten Abend,

    vielen vielen Dank für die ganzen Tutorials und Codes ! Das Beispiel mit dem USB CDC hat bei mir auf Anhieb funktioniert !


    • admin_ub sagt:

      so soll es sein, freut mich zu hören

  15. Felix sagt:


    Ich wollte mit deiner Funktion zum senden: UB_USB_CDC_SendString(char *ptr, USB_CDC_LASTBYTE_t end_cmd); die errechneten Werte eines ADC Senden. Habe dazu den Wert in einer U-int16 Variablen. Nur leider kommt bei mir nichts an, wenn ich den COM-Port mit Putty angucke. Code: UB_USB_CDC_SendString(adc_messwert, CRLF);

    Was muss ich noch tun, damit er mir den Wert sendet.

    LG Felix

    • admin_ub sagt:

      du musst die Zahl zuerst in einen String wandeln !!

      char buf[20];
      UB_USB_CDC_SendString(buf, CRLF);

      für sprintf wird bei CoIDE noch die “Retarget printf” benötigt

  16. Mehdi sagt:


    I have tried a lot to compile your code in linux using similar make file, include and libs from your other CDC sample. But no matter whatever I do I receive this error:
    ~/sat/bin/arm-none-eabi-gcc -std=gnu99 -g -O2 -Wall -Tstm32_flash.ld -mlittle-endian -mthumb -mthumb-interwork -nostartfiles -mcpu=cortex-m4 -msoft-float -Iinc -Ilib/Core/cmsis -Ilib/Core/stm32 -Ilib/Conf -Iub_lib -Iub_lib/usb_cdc_lolevel -Ilib/StdPeriph/inc -Ilib/USB_OTG/inc -Ilib/USB_Device/Core/inc -Ilib/USB_Device/Class/cdc/inc src/main.c lib/startup_stm32f4xx.s -o build/ub_stm32f4_usb_cdc_v104.elf -Llib/StdPeriph -Llib/USB_Device/Core -Llib/USB_Device/Class/cdc -Llib/USB_OTG -lm -lstdperiph -lusbdevcdc -lusbcore
    /tmp/ccCc7yln.o: In function `LoopFillZerobss’:
    /home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/lib/startup_stm32f4xx.s:97: undefined reference to `SystemInit’
    /tmp/cc9pDJPB.o: In function `main’:
    /home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:27: undefined reference to `SystemInit’
    /home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:31: undefined reference to `UB_USB_CDC_Init’
    /home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:36: undefined reference to `UB_USB_CDC_GetStatus’
    /home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:38: undefined reference to `UB_USB_CDC_ReceiveString’
    /home/mehdix/workspace/robotik/ub_stm32f4_usb_cdc_v104/src/main.c:43: undefined reference to `UB_USB_CDC_SendString’
    collect2: error: ld returned 1 exit status
    make: *** [build/ub_stm32f4_usb_cdc_v104.elf] Error 1

    The appropriate files are included but I can not comple. I appreciate if you can help me to compile this code.

    • admin_ub sagt:

      uhh, sorry … i dont know what to do under linux. Perhaps you should start with a smaller Projekt like the “Demo_01″ to verify your build chain and the right settings.

  17. X_X sagt:

    Gerade aufgefallen:
    Die Elemente der enums USB_CDC_LASTBYTE_t und USB_CDC_RXSTATUS_t kommen sich mit der UART-Lib ins Gehege. Ein Prefix à la “CDC_” schafft Abhilfe. Ggf. könnte man das in beiden Libs übernehmen.

  18. Werner sagt:

    Die Library funktioniert am STM32F4 Discovery wunderbar. Jetzt möchte ich aber auf das Microe Mini-M4 Board wechseln und dort bekomme ich USB nicht zum Laufen.
    Ich habe
    * CPU auf die STM32F415RG in CooCox Target geändert
    * HSE=16000000 gesetzt weil der externe Quarz dort statt 8MHz jetzt 16MHz hat
    * PLL_M von 8 auf 16 geändert um obiges auszugleichen und trotzdem 48MHz an USB zu bekommen (Mit STM32 Clock Config Excel Tool kontrolliert)
    * Die Software per MicroE HID Bootloader hochgeladen

    Nach einem Reset meldet sich kurz der Bootloader per USB, dann springt meine Software an aber ich bekomme keinen STM32 Virtual ComPort .

    Hat irgendjemand eine Idee was ich übersehen haben könnte? Memory Mapping wegen USB Bootloader? Ein De-Init am USB bevor ich obiges USB Init in main aufrufe? Code an sich läuft am Mini-M4 Board, UART macht was ich progrmmiert habe.


  19. DG1RTO sagt:

    Vielen Dank für diese umfassenden Werke :) Bin gerade dabei zu versuchen, deine Beispiele nachzuvollziehen. Komme aus der 8Bit-Ecke (AVR). Verwende das F4-Discovery Board.

    Mit compiliertem Beispiel”31″ meldet sich das Board bei mir als “Verbundgerät” unter WIN7 64Bit an.
    Com9 und COM10 möchte er gern installieren (Rest ist belegt). Klappt zu Fuß mit dem ST-vcp-Treiber für COM9. COM10 (natürlich) nicht. Wie auch… COM9 wird korrekt angezeigt, Port->open mit deinem Terminalprogramm geht auch. Es lässt sich aber nichts schreiben. (WriteFile Function failed (win error code:87))
    Ich habe auch schon versucht, COM10 danach zu “deaktivieren”. ist er dann auch. COM9 lässt sich trotzdem nicht nutzen.
    Ganz unten im Gerätemanager steht zusätzlich immernoch “USB-Verbundgerät”.
    Ich bin etwas ratlos…
    Danke! Axel

  20. DG1RTO sagt:

    Now i ran the setup “dpinst_amd64.exe “in the drivers folder provided by ST.
    Version 1.4.1. now it works. manually usb-driver installation of the recocnized board has failed.

    Ich habe die Setup.exe “dpinst_amd64″ im Treiberverzeichnis ausgeführt. (Win7/64bit)
    Vorher hatte ich versucht, die beiden seriellen Ports über “treiber aktualisieren” zum Leben zu erwecken, was nicht gelang.
    Das zwei Geräte angezeigt werden, sei in Ordnung.


    Danke und gruß


    • DG1RTO sagt:

      uups, formating failed :)

      • admin_ub sagt:

        ist das Problem jetzt gelöst oder nicht ?

  21. Domingo Molinero sagt:

    Hallo Uwe,

    ich bin ja ein begeisterter Benutzer deiner Bibliotheken, hat mir bei den ersten Versuche beim -Umstieg von 8- auf 32-Bit sehr viel geholfen und alles erleichtert. Dafür ein riesiges Dankeschön!
    Momentan arbeite ich am USB-CDC Beispiel, um mal auszutesten, welche Datenraten möglich sind. momentan habe ich ein Maximum von ca. 1,2MBit. Dazu sende ich von DiscoveryBoard aus alle 1ms dreimal hintereinander einen String mit 64 Zeichen Länge. Hier treten dann allerdings schon übertragungsfehler auf. die Strings gehen teilweise verloren. Sende ich alle 1ms nur zweimal 64 Zeichen, geht es noch glatt.
    Ich habe schon sehr viel experimentiert, längere Strings, geringere Wiederholrate, kürzere Strings schnelle Wiederholung, beides mehr, beides weniger, … . Schneller als ~135000 bytes/s bekomme ichs nicht hin.
    Empfang läuft über HTerm, eingestellt auf 4MBit (wenn höher, geht gar nichts mehr). Dein Terminal-Programm kommt bei mir sehr ins schwitzen, ich kann ohne Probleme verbinden und einen String senden, welcher die Übertragung startet, ab dann ist aber leider nichts mehr zu machen. Hast du vielleicht eine Idee, was da bremsen könnte? Ich habe andere Terminals schon versucht zu verwenden, allerdings ist oft die Baudrate, die Datenmenge oder ein fehlender Timestamp hinderlich.
    Bei Bedarf kann ich auch mal mein Projekt per Mail schicken.


    • Markus sagt:


      das Problem hatte ich auch. Sobald man große Datenmengen vom STM in den PC senden will, bricht die USB Verbindung zusammen und es gehen extrem viel Daten verloren.

      Habe damals lang rumexperimentiert, aber auch nicht hinbekommen :(

  22. Hello,

    Would be so kind and give me a little advice with the CDC project. I have succesfully using your library with no problem at all. But you have mentioned at the top of your article that you have been able to achieve about 7Mbit/s in some other project. Now I am achieving only about 1Mbit/s which is too low for my project and I am wondering where is the issue. When I was trying to send data faster via your lib it start to lost bytes. Is this is a problem on the side of the PC driver and its Endpoint handling in CDC mode or?

    I have also looked into the project where you have achieved about 7Mbit but I did not found any difference in the CDC lib.

    Thank you very much.


    • admin_ub sagt:

      7Mbit/s yes, but only in “receive” direction. In “transmit” other people have the same problems. I can try to find a solution, give me a few days.

      • Thank you for your time and support. I have tried to identify the problem as well. Maybe there will be problem on the computer side, but still I am testing it with no better result. It could be also problem that the COM port driver is handling endpoint IN in small size or not so frequently. Maybe there will be some way if the device will use only 2 bulk endpoints (IN and OUT) with no CDC intelligence and handle it with libusb driver or winusb driver on the computer side.

      • Please do you have something new in this issue? Thanks Jan

  23. Sam White sagt:

    I need your help…I have a great project for you to complete. I’m looking for a way to emulate an USB keyboard on a windows machine using the STM32F4 discovery. If you could start a simple program to get me started would be great such as pushing a button on the stm32F4 discovery board when plugged into a PC causes the PC to read it as ‘a’ from a keyboard being pushed…I would really appreciate the help…thank you

  24. Torben sagt:


    erst einmal viele dank für deine vielen tollen Libs.

    Ich benutze die CDC-Lib um Messwerte vom Sensor zum PC zu übertragen. Ich habe dabei jedoch ein kleines Problem und hoffe, dass du mir helfen kannst:
    Der Mikrocontroller macht erst einmal ein Datenpaket von 4096Bytes voll bis es an den Computer geht. Wie kann ich das abstellen? Ich möchte, dass die Daten asap an den Computer gesand werden, sonst kommt es dort zu unangenehmen Ruckel-Effekten bei der Darstellung.


    • admin_ub sagt:

      das kann nicht sein, denn dann würde obiges Beispiel von mir gar nicht funktionieren. Was sein kann ist, das in einem zu “langsamen” Zyklus gesendet wird. So wie ich es noch in Erinnerung habe liegen zwischen den USB-Packeten 1ms. Glaube aber nicht das man das schneller einstellen kann. Was für ein Programm hast du denn auf der PC Seite ? event. hat das keine “Echtzeit” Priorität und ist aus dem Grund zu langsam.

  25. Lucky1 sagt:


    erstmal Danke für Deine tolle Seite. Sie hat mir den Umstieg zum STM32 bis jetzt sehr erleichtert. Ich hänge jetzt allerdings an einem Problem fest. Gibt es eine Möglichkeit mit Deiner Lib statt einen ASCII String mit 0x0D Abschlussbyte, eine Binary-Sequenz mit fixer Länge und einer Startsequenz zu empfangen (z.B. 0xAA 0xBB 0xCC 0xDD +2048 Byte?

    Wäre super wenn Du mir da helfen könntest.


  26. Lucky1 sagt:

    Habe wahrscheinlich die Antwort im Capture Client gefunden.
    Werde es mal ausprobieren.



Wie hat Dir dieser Artikel gefallen?

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (1 Bewertungen, Durchschnitt: 5,00 von 5)

2 Antworten zu 31-USB_CDC-Library (STM32F4)

  1. Pierre sagt:

    Hallo Uwe, Hallo Manfred,

    erstmal großes Dank für die tolle Bibliothek, die haben wir in der Firma schon ein paar Mal verwendet! Die CDC Bibliothek haben wir schon letztens erfolgreich benutzt mit unserem STM32F4 Discovery Board und ich probiere jetzt sie wieder einzusetzen, habe aber nur mäßig Erfolg… Es scheint gerade, als ob ich in der Funktion UB_USB_CDC_SendData() „stecken bleibe“, bis ich auf Windows Seite in HTerm eine Sitzung öffne, wenn ich es gemacht habe funktioniert alles wie erwartet. Das passiert nur wenn der Micro USB steckt. Ich dachte erstmal vielleicht liegt das an den Treiber und es stellt sich heraus, dass der Virtual Com Port Treiber für STM32 für Windows 10 nicht mehr nötig ist, weil jetzt nativ CDC Geräte unterstützt werden. Für die damalige Projekte hatten wir auch noch nicht Windows 10 sondern 7. Kann das sein, dass die automatische Erkennung / Anmeldung jetzt mit dem neuen Treiber ein Problem ist? Wird intern der USB_CDC_STATUS nicht mehr korrekt erkannt? Verstehe ich was falsch?

    Schöne Grüße,


    • Pierre sagt:

      Ok, ich vermute jetzt dass es eigentlich ein „Feature“ ist ich bin nicht sicher. Auf jeden Fall hat es sich mit den anderen Betriebssystemen doch nicht anders verhalten. Ich finde trotzdem nicht intuitiv, dass die der USB_CDC_STATUS auf USB_CDC_CONNECTED steht und, dass die Funktion „blockiert“ ist weil in HTerm keine Verbindung hergestellt wurde.

      Ich habe das Problem gelöst indem ich FreeRTOS benutze, ich habe dann eine Task nur für die CDC Kommunikation und andere Tasks, die nicht unterbrochen werden falls die Kommunikation auf PC Seite noch nicht erstellt wurde.




Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert