USB Mass Storage (Flash Drive) doesn’t become ready occasionally?

[MZoli.1]

Recently I’ve run a code with stm32f429 in freertos in which usb host fs is enabled for mass storage class. I generated the init code with stm32cubemx ver. 6.4. At first only usb host is enabled and when the flash drive is inserted the usb host core detects it and shows its state as “APPLICATION_READY�?.

But when I add other tasks with different priorities and runtimes, sometimes the usb flash drive detection doesn’t complete. It means that when usb host core reaches “HOST_CLASS�? state and calls the class process function (USBH_MSC_Process) to handle the class background process, it can’t detect the MSC device as “ready�?. In MSC request state machine when the USBH_MSC_SCSI_Inquiry function is called to test if media ready or not, the ready_state remains busy (USBH_BUSY) and no longer becomes ready (USBH_OK), so the application state remains as “APPLICATION_START�?.

Clearly, some changes in other parts of the code has impacts on usb msc readiness in an irrelevant way. This may be aroused from stack memory or timing issues or using rtos. As I’ve tested, this issue doesn’t necessarily depend on the number of tasks or ram usage and something like that.  

I don’t know how I can solve this issue, please help me.

Thanks.

[Tesla DeLorean]

Instrument so you can understand the flow dynamics without a debugger.​

[MZoli.1]

I use Keil uVision5 and ST-link debugger.

[MZoli.1]

Could you help me please? I don't understand your answer. It's absolutely essential for me to solve this issue.

[Pavel A.]

This means, add some debug prints to understand where the flow is different between working and non-working. You cannot debug by setting breakpoints and step, because USB is sensitive to timing.

[Tesla DeLorean]

You add code to output diagnostic or telemetry information so you can understand how it interacts with itself in real-time, and how the behaviour in working and non-working conditions differ.

Add stack checking functions to determine depth/usage.

Add time stamping to the telemetry to see if that provides sufficient context.

Keep adding information until you understand what is happening and why.

Use bisection techniques to isolate the problem.

Add sanity checking at keys points you identify in the failure paths.

Recognize failure conditions, and retry.

Some flash drives have timing issues, lack crystals and barely meed USB specs. Use HSE clock on STM32 side