STM32 F4 – VCP confusion

Sysprogs forums Forums VisualGDB STM32 F4 – VCP confusion

This topic contains 3 replies, has 2 voices, and was last updated by  parsec67 1 week, 2 days ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #9992



    I’m curious whether the function below, part of the VisualGDB USB example, is supplied by ST or Sysprogs? It is located in usbd_cdc_if.c and for me it hangs on the second while (pCDC->TxState) {} if two character strings are sent directly one after another:




    I made a modified function of the above which works better, however, in my first version listed below, if the number of sent bytes exceed CDC_DATA_HS_OUT_PACKET_SIZE (=512 bytes) and the recursive call is invoked then garbage data will be injected after the first 512 bytes and before subsequent bytes are sent. Below, millis() just returns system ticks and USBTX_BUSYWAIT is defined as 2.




    My final modded function version which is able to send more than 512 bytes (my custom packet is exactly 1076 bytes, not tested larger sizes than this) without injecting garbage data is below. Basically I simply removed the buffer size check and recursive call.



    So I now have everything working as I want but trying to understand what is going on, e.g. how come that in my latest version exceeding the USB HS buffer size has no impact and actually improves quality of data? Also, shouldn’t there be a check for USB FS max packet size in the original VCP_Write() to begin with, which is 64 bytes? After all I’m not using HS here but rather FS.

    The above applies to ST’s Disco F407 and mikroElektronikas Mini M4 for STM32 (F415RG), testing on both boards produces the same outcome. All clocks/prescalers are set correctly. VCP driver on the PC  is ST’s own version 1.4.




    The VCP_write() function is provided by us and it’s based on the original sample from ST and it indeed contains a bug with HS instead of FS. The correct version should look like this:

    We have updated this internally and will include the fix in the next release of the BSP. Regarding packets larger than CDC_DATA_FS_OUT_PACKET_SIZE, they do sometimes work, but may not be fully supported by the hardware and hence may cause strange effects, so we would not recommend using them.



    Thanks, this does not work for me. With your bug fixed version I am still seeing noise on the data and with the corrected, reduced FS buffer limit it is now worse than before. Here is how the signal data looks — and should look — with my no-size-check version:

    And here is the equivalent output via VCP_write():

    To test further I disabled all irrelevant peripherals in my program to avoid interference and printed out this long string once every 5 seconds in a loop:


    In a terminal window (termite or SmartTTY) a single VCP_write() call outputs the below. Note that the string is not transmitted to the end and also clipped from start, one character at the time:

    I’ll keep investigating this during the remainder of the day to see if I can find the issue.

    • This reply was modified 1 week, 2 days ago by  parsec67. Reason: Spelling correction


    Okay then, after further investigation your VCP_write() must still have a bug. I wrote an alternate function with code stolen from inspired by Atmel SAM3X USB core lib and it works now. Here is my signal data looking good and all:

    And here is the function which should handle transmitting >64 bytes over USB FS correctly:


    Note also the long string mentioned in my previous post prints out correctly using this function. Now, where do I pick up my paycheck…? 😉

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.