3
\$\begingroup\$

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

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.