USBH_MSC_RdWrProcess loop stuck

STMicroelectronics / stm32_mw_usb_host

Provides the USB Host library part of the STM32Cube MCU Component "middleware" for all STM32xx series.

Other

32 stars 15 forks source link

USBH_MSC_RdWrProcess loop stuck #10

Closed NimaAgm closed 5 months ago

NimaAgm commented 1 year ago

Description I have USB Host application. This application would read files from USBs.

Describe the set-up

STM32F730
IAR Arm 8.40
I am using latest version of Stm32_mw_usb_host Describe the bug Bug is related to USBH_MSC_Read This function uses a while loop to get the usb state If state is USBH_BUSY it will stay in this function for too much time. further into function calls :USBH_MSC_BOT_Process would work based on the state of the URB_Status USBH_URB_NOTREADY is not handled in BOT_DATA_IN_WAIT this would result in USBH_MSC_RdWrProcess to USBH_BUSY and application to stay is this loop This for most of usb sticks would finish under 300 miliseconds but for some USB sticks it may take longer than 3 to 5 seconds which is a lot of time in embedded system would decrease the performance of any stm32 application

How To Reproduce

Even emi problem may cause this loop too
for example if you short D+ or D- or connect D+ to D- USB application would get stuck in this while loop

NimaAgm commented 1 year ago

Any news on this issue ?

NimaAgm commented 1 year ago

Any news on this issue ?

ALABSTM commented 7 months ago

See also STM32CubeF1#59

ALABSTM commented 7 months ago

Hi @NimaAgm,

Please excuse this delayed reply. Analysis is ongoing. I will keep you posted.

With regards,

ALABSTM commented 6 months ago

Hi @NimaAgm,

Regarding the USBH_MSC_Read() function, it looks you are right. I notice there is a timeout mechanism. However, local variable timeout seems to be left unchanged while it should be decremented each iteration.

https://github.com/STMicroelectronics/stm32_mw_usb_host/blob/3a524c2f185ac2f193cf3edd0b3f83ed064f3a5c/Class/MSC/Src/usbh_msc.c#L824-L830

Regarding the USBH_MSC_BOT_Process() function, it looks like you are right too.

Both points will be logged internally at the attention of our development teams. I will keep you informed.

With regards,

ALABSTM commented 6 months ago

ST Internal Reference: 175663

ALABSTM commented 6 months ago

ST Internal Reference: 175666

ALABSTM commented 6 months ago

Hi @NimaAgm,

Here is the answer of our development teams to the issue with the USBH_MSC_Read() function.

The timeout mechanism is based on the increment of phost->Timer with each interrupt trigged by a SOF.
This will result, at the end, in a timeout if the transfer fails, and the device gets disconnected.

Hence, there is no timeout issue according to them.

Regarding the issue related to the USBH_MSC_BOT_Process() function, the analysis is still ongoing.

With regards,

ALABSTM commented 5 months ago

Hi @NimaAgm,

Regarding the issue related to the USBH_MSC_BOT_Process() function, our development teams say there is no need to consider the sub-case URB_Status == USBH_URB_NOTREADY in case BOT_DATA_IN_WAIT for transfers to the IN EP. Indeed:

When the device NAKs the IN, the HW + HAL will manage to reactivate the channel.
This will result in a new IN EP on the bus, in case more data is expected to be sent from the device.

On the other hand, for transfers from the OUT EP, this request needs to be resubmitted by the MW in order to resend the same data.

I hope this makes things clearer. Please allow me to close this thread. Thank you for your comprehension and thank you again for your report.

With regards,