STM32F4 USB CDC Transfer Problems

[awoods177]

Posted on February 03, 2016 at 20:17

Hello,

My first post here, so please let me know if I leave any important information out. I am using the MCU as a USB CDC device attached to a BeagleBone Black, with the following settings:

__USB_OTG_FS_CLK_ENABLE();
hpcd.Instance = USB_OTG_FS;
hpcd.Init.dev_endpoints = 4; 
hpcd.Init.use_dedicated_ep1 = 0;
hpcd.Init.ep0_mps = 0x40; 
hpcd.Init.dma_enable = 0;
hpcd.Init.low_power_enable = 0;
hpcd.Init.phy_itface = PCD_PHY_EMBEDDED; 
hpcd.Init.Sof_enable = 0;
hpcd.Init.speed = PCD_SPEED_FULL;
hpcd.Init.vbus_sensing_enable = 0;
/* Link The driver to the stack */
hpcd.pData = pdev;
pdev->pData = &hpcd;
/*Initialize LL Driver */
HAL_PCD_Init(&hpcd);
HAL_PCD_SetRxFiFo(&hpcd, 0x80);
HAL_PCD_SetTxFiFo(&hpcd, 0, 0x40);
HAL_PCD_SetTxFiFo(&hpcd, 1, 0x80);

If it matters, I am using a baud rate of 115200, with 8N1 settings on the virtual com port. These match the settings MCU. When performing a short data transfer, everything works great. However, if I try to transfer large amounts of data (e.g., 1644 bytes) I get corrupt data on the BBB side. The data is just a series of floating point numbers (32bit) but on the receiving side, one of the numbers is always just slightly off. I send a checksum with the packet, and check it against a calculated one on the receiving side, and am consistently getting a mismatch between the two. Consistently, the number which is corrupted is the 178th number, which is somewhere in the range of 712th - 716th byte I think. I have not narrowed down the exact bit though. I can't make any sense of this pattern. For even longer transfers (e.g., 12012 bytes) I get similar errors within the data (149th number, 589th - 592 numbers) where the numbers are just not quite right (as if a bit is off or something). In addition to these errors, I also get a cutoff in data at the 1023rd number. After that, I get all zeros. SOMETIMES (~5% of the time), the midrange transfers go through just fine. Cable length? I didn't think USB suffered from this limitation though. I think it must be a software thing. Any help is much appreciated. Thank you! Alex

[awoods177]

Posted on February 03, 2016 at 22:58

To help illustrate the problem I am having, I sent an array of increasing 16 bit integers over the USB connection (e.g, 0, 1, 2, 3, 4, ...... 4090, 4091, 4092, 4093, 4094, 4095).

The 14th, 270th, 526th, etc. data points are corrupt (e.g, datapoint 14 SHOULD be 13 but it is 10, 270 SHOULD be 269 but is 266, etc). Always 3 lower than expected on corrupt points. This pattern (256 bytes between corrupt data) continues up until point 2047 at which point the data flatlines. This data is part of a larger ''packet'' which looks like the following: | BEGIN (1 BYTE) | HEADER (6 BYTES) | DATA (N BYTES) | CHECKSUM (4 BYTES) | The data is transmitted using the following calls:

USBD_CDC_SetTxBuffer(&USBD_Device, &begin, 1);
while(USBD_CDC_TransmitPacket(&USBD_Device) == USBD_BUSY);
USBD_CDC_SetTxBuffer(&USBD_Device, &txHeader[0], HEADER_LENGTH);
while(USBD_CDC_TransmitPacket(&USBD_Device) == USBD_BUSY);
USBD_CDC_SetTxBuffer(&USBD_Device, txData, txDataLength);
while(USBD_CDC_TransmitPacket(&USBD_Device) == USBD_BUSY); 
USBD_CDC_SetTxBuffer(&USBD_Device, &txChecksum[0], 4);
while(USBD_CDC_TransmitPacket(&USBD_Device) == USBD_BUSY);

Any suggestions? Thanks, Alex

[awoods177]

Posted on February 03, 2016 at 23:48

UPDATE:

I've solved the corrupt data issue. It turns out that my termios settings for receiving the data in Linux were not quite right and it was doing some form of input processing which it shouldn't have been.Additionally, Linux is set up with a 4096 byte buffer which I am willing to bet is why I get zeros for larger arrays. I haven't fixed this yet but I am now confident that it is not an MCU problem.Hopefully this informations helps someone else out there in the future!Alex

[Walid FTITI_O]

Posted on February 04, 2016 at 16:57

Hi woods.alex,

Thanks for your feedback and contribution. we appreciate your inputs of how you have fixed your issue. -Hannibal-