STM32 Virtual COM port baud rate

Question

I'm using the STM32 VCP firmware and I want to transmit data to my PC from STM32F4 discovery board. The configuration of the virtual COM port is fine, the properties are the following in device manager:

VCP configurations

In english: 9600 bit/s, 8 data bit, no parity, 1 stop bit, no hardware flow control. I'm trying to receive characters in Realterm with these parameters, but I don't get them, it looks like following:

Realterm screenshot

What could I do wrong?

EDIT:

The MCU sends with the following code snippet:

int main(void)
{
 HAL_Init();
 SystemClock_Config();
 MX_GPIO_Init();
 MX_USB_DEVICE_Init();
 uint8_t Buf[] = "test";
 HAL_Delay(1000);
 while (1)
 {
 CDC_Transmit_FS(Buf, 4);
 HAL_Delay(1000);
 }
}

• M D: What data are you sending from the MCU? How have you configured the display of RealTerm? It appears that the PC is receiving 0x00 repeatedly.
• Milan Tenk: I edited my question. The RealTerm display configuration is in ASCII, turning it in hex format, it gives really 0x00.
• Eugene Sh.: Are you giving it some delay between the transmits?
• Milan Tenk: Yes, there is some delay between the transtmits.
• Eugene Sh.: Can you show the enclosing code snippet?

Answer 1

The CDC_Transmit_FS implementation is buggy (at least in the version I am looking at):

uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len)
{
 uint8_t result = USBD_OK;
 /* USER CODE BEGIN 8 */
 USBD_CDC_SetTxBuffer(hUsbDevice_0, UserTxBufferFS, Len); 
 result = USBD_CDC_TransmitPacket(hUsbDevice_0);
 /* USER CODE END 8 */
 return result;
}

As you can see the Buff parameter is never used in the function. You might try modifying the function, by copying the Buff into UserTxBufferFS (using memcpy or whatever).

• Milan Tenk: You were right, using memcpy(UserTxBufferFS, Buf, sizeof(char) * Len); before USBD_CDC_SetTxBuffer(hUsbDevice_0, UserTxBufferFS, Len);, the data is transmitted, and I can see it in RealTerm. :)
• RBerteig: Wow, that is exceptionally buggy for vendor-supplied framework sample code. How did that possibly get through QC?
• supercat: @RBerteig: I've seen plenty of vendor-supplied framework code that was sufficiently rotten that I doubt any bugs ever caused any trouble because the code was just plain unworkable. The above function looks like it might have a shot of working if Buf happens to equal UserTxBufferFS.
• RBerteig: That was probably how it got through. I wish vendors spent a little more effort on code quality and testing for sample code.
• Jay Greco: This question was asked a while ago, but I thought I'd add: In the latest patch of ST's libraries this has been fixed. I thought this was breaking my code but it turns out it's not a problem. The fix was as simple as replacing UserTxBufferFS with Buf, apparently.