Posted on January 08, 2015 at 06:44The point of cisar.ivo.001’s post on above link is that
the ST’s original code writes to read-only registers, like OTG_FS_DTXFSTSx.
I ignored it, because it’s just redundant without harmful side effect.
> I have a problem when the USB connection to the PC is ended because App kill
> but at the some time keep the USB active so it can be connect again when the PC turn to the device?
> txstatus.d32 updated with DTXFSTS. Do you still see a problem and if it need to be fix? Your problem is,
- The USB connection is lost before the PC application retrieves all of packets on the bulk IN FIFO.
OR
- Your firmware code puts packet(s) to the bulk IN FIFO, after USB connection is lost.
In these ways, the FIFO keeps untreated packet(s) when the connection is recovered.
To cope with this problem, flush out the FIFO when the connection is established.
There are two timings to place this flush operation,
- bus reset
- Set_Configuration
I believe Set_Configuration is the better place, following to the concept of USB (the endpoints, other than the defaults, should be established at Set_Configuration / Set_Interface). But bus reset timing fits well for ST’s stack implementation.
In the VCP example on STM32_USB-Host-Device_Lib_V2.1.0, these callbacks are called by stack at bus reset (USBD_Reset() in usbd_core.c).
- usbd_cdc_DeInit() in \STM32_USB-Host-Device_Lib_V2.1.0\Libraries\STM32_USB_Device_Library\Class\cdc\src\usbd_cdc_core.c
- USBD_USR_DeviceReset() in \STM32_USB-Host-Device_Lib_V2.1.0\Project\USB_Device_Examples\VCP\src\usbd_usr.c
You’ll put this FIFO flush code into one of above callback,
DCD_EP_Flush( pdev, CDC_IN_EP );
Tsuneo
