cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F207 USB HPOST fail after reconnect

shamraydev
Associate
Posted on March 22, 2015 at 17:50

I found the problem. When I quickly connecting/disconnecting USB device(LS HID mouse)  from STM32F207 USB host FS port the occurs another situation: USB constroller  stop generate host channel and/or port/disconnect interrupts. But SOF interrupts always generates even when device is disconnected!!! It looks like this: I run STMEVAL32F4 board with USB HOST - all works right. If I now start quickly connect and disconnect USB cable,  then after a while USB device is no longer detected. Sometimes it does not generate even connect / disconnect interrupt. The USB HOST can normally work again only after reset. This situation also was founded in standart demo from STM. For example USBH hid mouse.

On the USBH HS with an external PHY all not worked properly. Problem occurs only when using internal FS with PHY.

The board is powered from an external power source 5B.

Someone knows what could be the problem?

Thanks.
1 REPLY 1
Dulan D
Associate II
Posted on June 29, 2017 at 10:19

Hello,

It is a long time since your post but I face exactly the same problem as yours, and even with latest ST Library V1.16.0.

It occurs very quickly when I connect/disconnect the USB cable several times in a row (max 3 times). Then the USB host MSC is not recognized anymore and a reset is needed. After some USB traffic analysis, the GetDescriptor() method is not called anymore after the reset is sent.

I think I found a workaround for this issue: All ST Library and Keil libraries for the USB Host have their Host pool size set to 512 bytes. This is far too low. Trying with 2048 bytes it works much better and the rate of failure after some disconnect/reconnects of the USB cable drops down of about 90%. A value of 1024 is definitely too low and still cause the issue.

For the ST Library V1.16.0, you will need to change this line in the usbh_ctlreq.h file:

USBH_CfgDesc[512];

to

USBH_CfgDesc[2048];

For Keil MDK-Middleware (Professional edition), you will need to change this line in their USBH_Config_0.c config file:

#define USBH0_HC_MEM_POOL_SIZE 512

to

#define USBH0_HC_MEM_POOL_SIZE 2048

This is still a workaround and the problem is still there: Even after lot of connect/disconnect operations it will happen again on ST lib (Keil middleware did not fail in my tests).

Hence there are some other issues in the ST lib that must be solved. Apparently, the interrupt is hidden for a little while and if we disconnect during that time, the state machine of the lib is corrupted and can't recover at all.

I hope STM will fix this issue which is so easy to reproduce with any F4 discovery board, as it affects all USB users even for F3, F2 and F0 customers. ST could be great if the firmware they provide for their MCU would be more stable and debugged. It is not complicated to do it better so I hope they will fix it.