Why are additional characters appearing in VCP pClassData?

[ZThat]

I am using the USBD driver provided by your company to communicate via USB as a virtual com port in STMCube32_FW_F7_V1.7.0. I am using the STM32F7 series. When I receive messages, the buffer fills with additional characters at the end. 

I have not edited the USBD_CDC.c file, or the interrupts that lead to it. And the additional characters fill the pClassData buffer. This means that none of the data buffers that I have added to the program are adding these characters. They are being inserted before my code manipulates the data at all.

Sometimes these additional characters are messages that were previously sent by the device (ex. device sends "HELLO" then the PC sends back "HI" and I receive "HIh23HELLO". Other times they are seemingly random, but consistent (the same for multiple messages (HELLOasd, GOODBYEasd), or only the same for the same message (HELLOasd, GOODBYEdrt5, HELLOasd, GOODBYEdrt5)) depending on a variety of factors. The type of response depends upon the type of terminal I am using on the PC to communicate, but sniffing the terminal line with a serial port monitor shows that no additional characters are being sent. 

Sometimes the additional characters only present themselves after a specific message is sent to the device (ex: I send the device several messages and they are accurate. Then I sent ABCD. Then every subsequent message received by the device appends assdf\rllkj\r). Sometimes they correlate with keys that are being pressed on the keyboard (ex: pressing A in terraterm the device reads Aiej, pressing B in terraterm the device reads Bwer. The characters following the initial character are consistent for the initial character but vary between characters). 

Please provide some direction on what might be happening here.

Thanks

[ZThat · Accepted solution]

I have actually solved this issue by saving the length of the message received in a static variable to access later. This length gets passed through the callback structures of the interrupt. Previously I had been calculating the length of the message buffer with a strlen command. The moral of the story being, don't ever calculate the length of the received buffer on your own when using STM32F7 USB device drivers. Use the length that they give you in the callback. The read buffer gets filled with all kinds of nonsense that varies depending on all kinds of factors, but the beginning of it will be the correct message.