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.

AM3358: Send data to end point after USB Host detached

Part Number: AM3358

Tool/software: Starterware

There is a strange question from customer, When USB Host is detached, write a packet of data to endpoint FIFO, will it generate abnormal interrupt like of time out, NAK, etc?

They were using Starterware, program by themself, just need to know the mechanism to fix a software bug after sale.

  • Hi Tony,

    I assume the AM335x USB is in host mode?

    What is the reason of this question? to identify if the USB device is detached or not? or any different reason?

  • AM335x USB is device, it sends a frame of data after detached, result in it stay in none free state, can't send out data after reconnected. 

  • If the Starterware USB driver use interrupt mode, I believe the USB controller generates DISCONNECT interrupt when detached.

    If the driver doesn't use interrupt mode, the code should check the MUSB DEVCTL register, bits 3-4 = 0x11 means VBUS present, 0x0 means VBUS absent (detached), then the software should clean up for next attach.

  • If the Starterware USB driver use interrupt mode, I believe the USB controller generates DISCONNECT interrupt when detached.

    Yes, there is DISCONNECT interrupt. but their application send a frame data after DISCONNECT which caused the problem.

    If the extra frame data after disconnection can generate interrupt?

    Customer tracked the data has been written to endpoint, it should send out from endpoint according to TRM even disconnected, then should generate some interrupt of NAK, TXRDY or timeout, but did not observe that.

    Customer would like to know the mechanism to implement bug fix.

  • Hi Tony,

    There won't be any interrupt for the transmit failure in this case. and there is no any other status register to tell the host is gone. The only solution that I can think of is to use the DISCONNECT interrupt to clean up the sw state machine.