STM32F205 USB core reset for close port

[Barbie]

Posted on January 05, 2015 at 14:24

Hello.

I am using stm32_vcp_1.3.1 stack for USB OTG. I have a problem when the USB connection to the PC is ended because App kill (no interrupt to tell me about it). I found that I stay in a loop of OTG_FS_IRQHandler, and couldn't get to the main because of it. But I can add a check in that IRQ and know if the APP was kill. My question if I can use the function USB_OTG_STSUSB_OTG_CoreReset to break the IRQ loop but at the some time keep the USB active so it can be connect again when the PC turn to the device?  #stm32f205-usb-reset

[tsuneo]

Posted on January 05, 2015 at 21:15

> I am using stm32_vcp_1.3.1 stack for USB OTG.

VCP_v1.3.1 (stsw-stm32102) is the version of Windows driver. What is your firmware library, exactly? If it is STM32_USB-Host-Device_Lib_V2.1.0 (STSW-STM32046), apply this fix.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flooded%20empty%20FIFO%20interrupts%20still%20make%20USB%20devices%20crawl

Tsuneo

[Barbie]

Posted on January 06, 2015 at 10:19Thanks it fix the problem.But waht about what 

Lvo say at the some discussion ''

 I encounted one more problem with the function DCD_WriteEmptyTxFifo(), specifically with the code line

txstatus.d32 = USB_OTG_READ_REG32( &pdev->regs.INEP_REGS[epnum]->DTXFSTS);''

I don't understand whats wrong there. I see from the function that it do exactly what he say it doesn't. 

 txstatus.d32 updated with DTXFSTS. Do you still see a problem and if it need to be fix?

ReagrdsBar.

[tsuneo]

Posted on January 08, 2015 at 06:44

The 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