• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 451 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

RTOS/TM4C1294NCPDT: Recovering after USBMSCHFatFs_waitForConnect

RTOS/TM4C1294NCPDT: Recovering after USBMSCHFatFs_waitForConnect

Roger Lewis
Prodigy 20 points
Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

This is further to the post that Tushar made.

I am experiencing the same  issue where the wait for connect function will "hang"

This is repeatable, and removing the USB stick and then replacing it will correct the issue.

However, this workaround is not acceptable in our application.

If I had access to the source for the USBMSCHFatFs_waitForConnect() function, I could possibly fix the issue.

Alternatively, if someone could provide the code sequence that will gracefully shut down the FAT FS and USB stack so that when it is re-initialized, it works, that would be good.

In the meantime, I will have to provide a workaround that will be less than optimal.

Thanks

-Roger

  • 0
    TI__Guru* 96960 points
    The code for USBMSCHFatFs_waitForConnect is included in the TI-RTOS product. You can copy <TI-RTOS Install Dir>\products\tidrivers_tivac_2_16_01_13\packages\ti\drivers\USBMSCHFatFs.c and <TI-RTOS Install Dir>\products\tidrivers_tivac_2_16_01_13\packages\ti\drivers\usbmschfatfs\USBMSCHFatFsTiva.c into your project and change them as needed.

    Todd
  • 0 in reply to ToddMullanix
    Prodigy 20 points

    Thanks for that, Todd...

    I found and  examined the source code mentioned above and have a question regarding its logic.

    The code forces a wait (via semaphore) only when the USB stack's state is "no device present" (USBMSCHFatFsTiva_NO_DEVICE)  and returns a true for any other state.

    The confusing part is that there are three other possible states, as given by the following enum:

    typedef enum USBMSCHFatFsTiva_USBState {
    USBMSCHFatFsTiva_NO_DEVICE, /*!< No device is present. */

    USBMSCHFatFsTiva_CONNECTED, /*!<
    * Mass storage device is being
    * enumerated.
    */

    USBMSCHFatFsTiva_UNKNOWN, /*!<
    * An unsupported device has been
    * attached.
    */

    USBMSCHFatFsTiva_POWER_FAULT /*!< A power fault has occurred. */
    } USBMSCHFatFsTiva_USBState;

    So, by that logic, the wait function will return  a true when the device is connected, unknown or there is a power fault.

    Are there other services that would have invalidated the drive in the meantime, or would the open() function have returned a NULL if the states are unknown or faulted?

    Or is this a design flaw?

    More  importantly, is there any other mechanism that can be used to verify that a valid drive is inserted in the USB port?

    Thanks,

    -Roger