• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 1753 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.

USBHCDPipeWrite hangs if sending more than 64 bytes

Glenn Vassallo
Guru 21435 points


I can successfully send packets of up to 64 bytes to my device using USBHCDPipeWrite, however if I go over that amount USBHCDPipeWrite loops at the // Wait for a status change section at line 1625 of usbhostenum.c .

Its status is stuck on ePipeWriting.

USBHCDPipeWrite does have code to handle writing greater than 64 bytes to the Bulk Out, so I have not developed this code my self.

Everything works fine when sending less than 64 bytes. My device is a CDC ACM, I developed the driver my self based on the FTDI example (http://processors.wiki.ti.com/index.php/Stellaris_-_USB_Host_FTDI). I can send packets greater than 64 bytes in size to this device with a Windows program I have developed.

My code is almost identical to that which is included in the USBHFTDIWrite function of the FTDI example.

I am not sure how my code could be involved in this issue, as USBHCDPipeWrite works fine when sending packets of under 64 bytes and the handling of packets greater than 64 bytes is managed by USBHCDPipeWrite.

Any assistance in resolving this issue is greatly appreciated.

  • 0
    TI__Intellectual 2790 points

    Hello Glenn Vassallo,

    Can you attach a USB protocol analyzer to monitor the activity? Also, are you using uDMA?

  • 0 in reply to Stellaris Mitch
    Guru 21435 points

    Hi Mitch,

    Thanks for responding to my query.

    I have performed additional research and believe I have discovered a bug in usbhostenum.c - USBHCDPipeWrite() - Line 1595

    It is currently:-

    ui32ByteToSend = ui32Size;

    It should be:-

    ui32ByteToSend = ui32RemainingBytes;

    By constantly resetting the value to ui32Size (which is the total size of the original packet) you never reach a state of having no bytes left to send.

    I have made this change and I am now able to send packets to my device successfully.
     

    I am using the latest TivaWare - " This is part of revision 1.1 of the Tiva USB Library" is in the comments section at the top of the file.

    I am not using DMA,  when I tried this setting I got the same results. I have not tried to debug the DMA section to find what might be causing this, there is not a piece of similar code in that section. Also the State it is stuck on is ePipeWriteDMAWait, which is different when using non-DMA bulk out.

  • 0 in reply to Glenn Vassallo
    Guru 21435 points

    Hi Mitch,

    Some more information on this bug. The above fix only works for packets less than 128 bytes. For packets greater than this, it will also require the following code change on line 1586

    From this:-

    if (ui32ByteToSend > 64)

    To this:-

    if (ui32ByteToSend >= 64)

    There may be an issue with packets of multiples of 64, my device does not process such packets, so I have not tested for it. And of course a bunch of other stuff could be going on....so I'll leave it to you guys to find a fix for all cases.

  • 0 in reply to Glenn Vassallo
    TI__Intellectual 2790 points

    Hello Glenn,

    I'm glad to hear things are working for you.

    I agree the ui32RemainingBytes should be used in place of the ui32Size. This appears to be the right way to fix the issue based on the ui32ByteToSend value change in the ePipeDataSent when less than 64 bytes remain. That would certainly cause problems on the next pass of the loop.  The uDMA case will also fall through to that logic when the size doesn't allow for uDMA usage. So it seems to be a problem in all cases for certain data sizes and has somehow escaped detection.

    I'm not sure why the >= changes is making any difference for you, however.

    I will open a bug and have this fixed in the next round of TivaWare and I will include a note on your >= change and request a range of data sizes be tested. Thank you for bringing it to our attention!

  • 0 in reply to Stellaris Mitch
    Guru 21435 points

    This bug was not resolved in TivaWare 2.0.1.11577 release.

    Just updating this thread in case anyone else comes across the problem.

    Resolution is included in this thread.

    Glenn.