USBHMSCDriveReady() can take extremely long time to execute

Dave Hohl

I spent quite a bit of time yesterday trying to get my code to recognize a USB stick. Every time I plugged it in, my code would go crazy, going into a continual reset mode where breakpoints would not work. I finally discovered that the call to USBHMSCDriveReady() in my OTG polling loop was taking nearly 1.4 seconds to execute. Since I have the watchdog timer configured to reset the system after 500 ms, the code would never get a chance to return from the call to USBHMSCDriveReady().

Now that I know what is going on, I have resolved the problem by disabling the watchdog during the call. But I wanted to share my discovery in case others may experience similar problems in the future.

Also, there is no mention in the USB Library User's Guide regarding the large amount of time this function can remain captive. Seems like it would be a good idea to add a note in the documentation that it can take a long time for the function to return. I imagine it probably depends on the type of drive plugged in.

Regards,

Dave

over 9 years ago

Amit Ashara over 9 years ago

TI__Guru**** 244400 points

Hello Dave,

Could it be an issue with the scheduler that is running the Tick Counter. Thanks for bringing this up.

Regards
Amit

Dave Hohl over 9 years ago in reply to Amit Ashara

Expert 2315 points

Hi, Amit,

The RTOS is configuring the system tick for 1000 Hz. Does the USBHMSCDriveReady() function make use of the system tick?

Regards,

Dave

Amit Ashara over 9 years ago in reply to Dave Hohl

TI__Guru**** 244400 points

Hello Dave,

Not sure on the RTOS implementation, but the bare metal does use the SysTick to schedule events.

Regards
Amit

Dave Hohl over 9 years ago in reply to Amit Ashara

Expert 2315 points

Hi, Amit,

I have a task that calls the OTG polling function every 2 ms normally. If my system is in Host mode, it calls USBHCDMain() and then checks the MCS status, which involves calling USBHMSCDriveReady().

The issue is that the USBHMSCDriveReady() function takes 1.4 seconds to execute. Does it go into some sort of captive delay that depends on the state of the tick counter? I tried stepping into the lower level functions but did not see anything like that.

Regards,

Dave

Amit Ashara over 9 years ago in reply to Dave Hohl

TI__Guru**** 244400 points

Hello Dave,

I am just thinking out loud: Is it because of RTOS or USBHMSCDriveReady API. Can we check it with the bare metal example in TivaWare for Host mode with a MSC Class Device?

Regards
Amit

Dave Hohl over 9 years ago in reply to Amit Ashara

Expert 2315 points

Hi, Amit,

I added some code to the usb_host_msc project to measure the number of ticks that elapsed during the USBHMSCDriveReady() execution. It is 137 ticks. Since the tick clock freq is 100 Hz (10 ms/tick) that means that it took 1.37 seconds -- same as I measured with my RTOS-based code.

Regards,

Dave

Amit Ashara over 9 years ago in reply to Dave Hohl

TI__Guru**** 244400 points

Hello Dave,

Thanks for the effort. So the issue is with the base library in not being too fast. Note that the USB compliance for Host enumeration is fairly relaxed. I can suggest reducing the SysTick timer value for the events to be closely placed.

Regards
Amit

Arm-based microcontrollers

Arm-based microcontrollers forum

USBHMSCDriveReady() can take extremely long time to execute