AnsweredAssumed Answered

Lightweight semaphore corruption in USB stack

Question asked by deadwoods on Oct 19, 2012
Latest reply on Oct 19, 2012 by deadwoods

Good morning,

 

I'm attempting to integrate the MQX USB host stack (specifically the mass storage device class) onto our bespoke hardware -- currently using a Kinetis K61 part. The aim is to be able to read and write the filesystem on a USB stick. We're using MQX 3.8.0 with CodeWarrior 10.2, and the USB peripheral is the full-speed one, so I'm using the KHCI low-level driver.

 

We're not using MFS as the filesystem; we're using a third-party solution, but I'm attempting to use the USBMFS layer in the USB host stack, which (as far as I can tell) isn't dependent on the filesystem implementation, but provides a device to access a reasonably generic USB stick.

 

This all works well, up to a point. I can detect insertion and removal of the USB stick and I can read arbitrary sectors. However, after a few transactions, I'm finding that the USB stack falls over. This manifests itself as the COMMAND_DONE semaphore in the USBMFS layer returning from its wait without the semaphore being posted. I've verified that it isn't just a timeout occurring by waiting indefinitely. Upon further investigation, it appears that the semaphore is becoming corrupt (a call to _lwsem_test() returns the COMMAND_DONE semaphore). Interestingly, the semaphore doesn't appear to be corrupt prior to the first time the wait fails, but it does afterwards.

 

The semaphore appears to become corrupt consistently, given the same set of USB transactions. I was wondering if anyone had come across something similar, or if anyone knew of scenarios that can cause lightweight semaphores to become corrupt. It's rather difficult to debug without understanding why this can occur!

 

Thanks in advance for any help!

Outcomes