Data dropout in VCP USB application

[hh.bakker9]

Posted on June 27, 2012 at 05:20

Hi,

I am working on a vibration sensor project where I need to send data from an accelerometer over USB to a computer application with a data loading of about 24 bytes per millisecond. I am using using a custom-built STM32 board that looks like an EVAL-C board (STM32F107) to the Atollic TrueStudio IDE I'm using.On the software side, I have used the Virtual COM Port driver example as a starting point using the 3.3.0 OTG_FS library. I have used this code for about a year now in low-data-rate applications without any significant problems.Everything works fine apart from the fact that I'm losing 16 bytes of data from the occasional (64 byte) packet and that the Tx FIFO then goes out of synch by one entry. That is, if I have data packets 1,2,3 etc that are sent in different frames and packet 1 loses 16 bytes, then packet 2 will not be sent until packet 3 is supposed to be sent, 3 not sent until packet 4 is supposed to be sent etc. If more packets drop data the Tx FIFO will go out of synch by one entry for each partially lost packet. The 16 bytes appear to be lost from the start of the packet.Received packets are not affected and I can still talk to the STM. If I stop the transfers and ask it for a response it will send the next transfer off the FIFO, that being the transfer that was supposed to be sent n writes ago, where n is the numb of partially-dropped packets.I have played about with the transfer size and this happens whether or not only one packet is sent per transfer, a full or partial packet is sent, or not. I am presuming that there is something that I have not implemented properly in altering the Virtual COM Port example but I have spent several days on this and, apart from knowing a lot more about USB that I did (or want to), have not managed to pinpoint the problem.Any help or pointers would be very gratefully accepted.regardsHuub #stm32-vcp-usb

[tsuneo]

Posted on June 27, 2012 at 15:22

> On the software side, I have used the Virtual COM Port driver example as a starting point using the 3.3.0 OTG_FS library.

Do you mean it's an old OTG_FS library? Then, it has TXFE bug on PCD_WriteEmptyTxFifo() (otgd_fs_int.c) This bug reduces transfer performance significantly. For the details of this bug and its fix, refer to this post. https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Yet%20another%20STM32F1057%20USB%20OTG%20driver%20issue%20%28VCP%20device%29 This bug has been fixed on current STM32_USB-FS-Device_Lib_V3.3.0 http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/um0424.zip Tsuneo

[hh.bakker9]

Posted on June 27, 2012 at 20:08

Hi Tsuneo, thanks for replying.

>STM32_USB-FS-Device_DriverThat is the one I am using, STM32_USB-FS-Device_Driver 3.3.0 March 2011. Sorry for the incorrect name in my earlier post. Also, the error mentioned in the post you cite is with the OTG routines not the FS routines that are used in Device mode.regardsHuub

[Tesla DeLorean]

Posted on June 27, 2012 at 21:58

See also

http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32_f105-07_f2_f4_usb-host-device_lib.zip

From March 2012

[tsuneo]

Posted on June 27, 2012 at 23:09

Sound like packet overwrite occurs on the TX FIFO.

Do you check the transfer completion flag (USB_Tx_State) before calling USB_SIL_Write()?

void Handle_USBAsynchXfer(void)  (hw_config.c)

{   if(USB_Tx_State == 0)   {     ...     USB_Tx_State = 1;     USB_SIL_Write( ... );   } } void EP1_IN_Callback(void) (usb_endp.c) {   ...   USB_Tx_State = 0; }> the error mentioned in the post you cite is with the OTG routines not the FS routines that are used in Device mode. On STM32_USB-FS-Device_Driver 3.3.0 (and in old stacks), otgd_fs_ file name prefix means STM32F105/107 in Device mode. Tsuneo

[hh.bakker9]

Posted on June 28, 2012 at 05:22

I didn't think that this was the problem because I'm only sending one packet every 5ms and there is no other traffic on the bus. I tried this anyway but the problem is unchanged.