4
\$\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\$
17
  • \$\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
    Commented Mar 13, 2015 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\$
    – Milan Tenk
    Commented Mar 13, 2015 at 20:50
  • \$\begingroup\$ Are you giving it some delay between the transmits? \$\endgroup\$
    – Eugene Sh.
    Commented Mar 13, 2015 at 20:55
  • \$\begingroup\$ Yes, there is some delay between the transtmits. \$\endgroup\$
    – Milan Tenk
    Commented Mar 13, 2015 at 21:00
  • \$\begingroup\$ Can you show the enclosing code snippet? \$\endgroup\$
    – Eugene Sh.
    Commented Mar 13, 2015 at 21:01

1 Answer 1

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\$
5
  • \$\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\$
    – Milan Tenk
    Commented Mar 13, 2015 at 21:55
  • \$\begingroup\$ Wow, that is exceptionally buggy for vendor-supplied framework sample code. How did that possibly get through QC? \$\endgroup\$
    – RBerteig
    Commented Mar 13, 2015 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
    Commented Mar 13, 2015 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
    Commented Mar 14, 2015 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
    Commented Jan 27, 2016 at 6:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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