STM32 Virtual COM port baud rate

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:

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:

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);
}
}

• 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. – M D Mar 13 '15 at 20:41
• I edited my question. The RealTerm display configuration is in ASCII, turning it in hex format, it gives really 0x00. – Milan Tenk Mar 13 '15 at 20:50
• Are you giving it some delay between the transmits? – Eugene Sh. Mar 13 '15 at 20:55
• Yes, there is some delay between the transtmits. – Milan Tenk Mar 13 '15 at 21:00
• Can you show the enclosing code snippet? – Eugene Sh. Mar 13 '15 at 21:01

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).

• 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. :) – Milan Tenk Mar 13 '15 at 21:55
• Wow, that is exceptionally buggy for vendor-supplied framework sample code. How did that possibly get through QC? – RBerteig Mar 13 '15 at 23:26
• @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. – supercat Mar 13 '15 at 23:45
• That was probably how it got through. I wish vendors spent a little more effort on code quality and testing for sample code. – RBerteig Mar 14 '15 at 2:17
• 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. – Jay Greco Jan 27 '16 at 6:42