• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 454 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.

USB Endpoint 0 control Transfers

William Kozlowski
Prodigy 200 points
Other Parts Discussed in Thread: SYSBIOS

I am using an EVM3359 development board to develop code for a project.  We are using Vendor Specific requests to transfer data back and forth on Endpoint 0.  When I have a device to host transfer which has a data phase which is a multiple of 64 and I follow this request with a request with one for a host to device data transfer the second request produces a stall condition.

The setup packet of the second request arrives in the chip without a problem.  The setup packet is acked and I receive an interrupt for EP0 indicating the data should have arrived but the rxPktRdy bit is not set indicating data is in the FIFO.  It appears the chip is just eliminating the data packet.

I can get the chip to function correctly if the transfer size of the first request is not a multiple of 64 or if the second request doesn't have a data phase as part of the request.

Unfortunately the Host side software has been released with other products and can't be changed.  So any help would be appreciated.  This appears to be a hardware issue and not a software issue

  • 0
    TI__Mastermind 27890 points

    Hello William,

    We have not seen this issue reported previously, but based on the description it would appear to be SW related as transfers to EP0 would be using PIO mode. Any transfer from 0 to 64 bytes should be fine.

    I assume you are operating the 3359 in Device mode. Is this correct?

    What OS are you using on the EVM?

  • 0 in reply to -DK-
    Prodigy 200 points

    We are using sysbios and operating the USB in device mode.

    The code we use has data phases for endpoint 0 transfers of up to 4096 bytes.  These are sent 64 bytes at a time with acknowledgements after each 64 byte transfer.  If the last transfer is a multiple of 64 the final data phase is a null data transfer.  When this occurs if the next command is a host to device transfer with data then a stall is produced.  I was able to clear the stall condition by inserting a dummy command which did not have a data phase operation between the two.

    If the original transfer is for 63 or 65 bytes then the last transfer contains either 1 or 63 bytes and there isn't a null data phase and there isn't the need to insert the dummy command.  The stall occurred for any size of transfer like 64,128, 192 ... 4096.  Any other value seems to work.

    The data for the next command never shows up in the chip but the chip itself generates an interrupt as if the data has arrived but the FIFO count is 0.

  • 0 in reply to William Kozlowski
    TI__Genius 13235 points

    Hi William,

    Does your USB subsystem operate in DMA mode and have more than one endpoint transferring data? I found an advisory on this issue in the AM335x silicon errata, which may apply to your issue. I have included a link to it below. Please let me know if this addresses your issue or provides any insight into the problem.

    Advisory 1.0.13: USB: Data May be Lost When USB Subsystem is Operating in DMA Mode and More Than One Endpoint is Transferring Data

    AM335x Silicon Errata: http://www.ti.com/lit/er/sprz360c/sprz360c.pdf (see page 16)

    Thanks,

    Clinton

  • 0 in reply to Clinton Rodgers
    Prodigy 200 points

    During this operation we are not using DMA for any other transfers.  We basically use endpoint 0 to send a command to the device and after any data is sent or received via endpoint 0 a response is sent on an interrupt endpoint without using DMA.

    I did see the errata you spoke about and it sounds like the same symptom but with a different cause.

  • 0 in reply to -DK-
    TI__Genius 13235 points

    DK,

    Do you have any further insight into this issue?

    Thanks,

    Clinton

  • 0 in reply to Clinton Rodgers
    TI__Mastermind 27890 points

    Sorry, no. As of yet we have not been able to reproduce this issue using Linux. 

  • 0 in reply to -DK-
    TI__Genius 13235 points

    Hi William,

    Have you made any progress with this issue? If the problem has changed at all, please give us an update.

    DK,

    Is there any additional information William could provide to help you recreate the issue? Could you suggest any trouble shooting methods to help him isolate the problem?

    Thanks,

    Clinton