• State
  • Locked Locked
  • Replies 24 replies
  • Subscribers 31 subscribers
  • Views 3315 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

64 byte USB packet

Yan Li29
Expert 1015 points

I am currently running Media Transfer protocol over BULK endpoints on a TIVA processor.  I have noticed that the USB link hangs when messages are sent that are multiples of 64 bytes.  I have gotten around this issue on the TIVA transmit side by detecting this situation and transmitting an extra byte.  However, on the receive side (OUT endpoint) I cannot control how much data the host sends.  Every time the host sends a message that is a multiple of 64 bytes, the USB link hangs.  I would have to unplug the USB cable and plug it back in to revive the link.  I have seen numerous posts regarding the IN endpoint but nothing on the OUT endpoint.  Has anyone else encountered this issue and have a solution?  I have attached a screenshot of the Beagle sniffer trace of the USB messages - error occurs at msg index 604 .

-Yan

  • 0
    TI__Guru 59540 points
    Hello Yan,

    I have forwarded your question to one of our USB experts. The should get back with you shortly.
  • 0
    TI__Guru**** 244380 points
    Hello Yan,

    We have tested the usb_bulk_device example with 64 byte packet and it works as expected. Did you try running the usb_dev_bulk example to check the same?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1015 points

    Amit,

    I ran the bulk example and it indeed works.  However, there is one big difference.  The example provided never sends a Zero Length Packet which is required for bulk transfers when the message is an exact multiple of 64.  So the bulk example is not correctly performing bulk transfers.  See attached Beagle sniffer capture of the bulk example.  I suspect that if a Zero Length Packet is sent, the TIVA USB device will stall.

    -Yan

  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan

    In the original snapshot you shared the ZLP is sent after a Setup packet. The ZLP is a requirement for IN and OUT tokens and not for SETUP tokens. If you can show me a case where is doing after an IN or OUT packet of 64 bytes and then a Stall is sent then it would be more useful. Also do note that on the USB bus a STALL is an indication of an error with the packet (for which I would suggest checking your application call of the usb library).

    I am not declining a bug in the usb library but I would need more data on this issue and I shall keep all possible root cause of the issue open till we can progressively eliminate each one of them.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1015 points
    Amit,

    Please look at my original snapshot again. The ZLP is sent at the end of the Vendor Op code that starts at Index 604. The ZLP is at Index 637, which terminates the Vendor Op code Data Block. Although the Response Block is sent properly through the IN endpoint, it seems that the OUT endpoint is already down. After a 2s timeout, the host sends the Get Device Status Request and the USB link is already stalled.

    Yan
  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan,

    The ZLP must be sent with an IN token and not an OUT token after having sent packets with OUT transaction Thus the transaction at Index 637 is an illegal transaction.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1015 points
    Amit,

    You are essentially making up your own protocol at this point. You are essentially saying that the recipient of a letter should mail the letter. The whole purpose of the ZLP is for the sender to signal end of message to the recipient. Your last 2 replies were a rush job to dismiss my query. If you are unwilling to put an effort to help, please do me the favor and pass this issue to someone who is willing to help.

    Regards
    Yan
  • 0 in reply to Chuck Davenport
    Expert 1015 points
    Chuck,

    I await help from your USB experts. So far I have put in time and effort to present my case, but have only received quick answers meant to brush off my issue.

    Regards,
    Yan
  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan,

    No. I never said that. You implied that. And I do not do rush jobs.....

    After the OUT transaction from the host (in the data stage) to TM4C which is a device, the host must send an IN transaction type to which the device shall respond with a ZLP which completes the status stage. In the first snapshot you are doing OUT transactions and have not shown any elaboration of the transactions in question.

    I am willing to help, but to reproduce the issue, I would need your project database, host application and steps to reproduce the same, so that I can emulate the failure and then debug the issue from the device framework (which is TM4C) in this case.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1015 points
    Amit,

    As the host is the one sending the message to the device, it's the host's responsibility to signal EOP. As the IN transaction is for device to host transmission, the host is unable to signal EOP through the IN transaction. From all the reading that I have done, the sources all say that the sender issues the ZLP. In addition, of all the devices that I have sniffed, for host to device transactions, the host sends the ZLP in an OUT transaction to terminate the packet. For MTP, the host additionally sends a IN token to the device to allow the device to send a response packet to the host.

    The code is embedded into a project that only runs on a custom hardware. I would have to extract the USB code from the project which will take at least a week. In addition, there is IP in the USB code that I would need to get approval before sending it outside of my company.

    It would be much simpler if someone on your team can modify the sample command prompt code to send a ZLP and see if the TIVA can handle the ZLP.

    Yan
  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan,

    It would take me a few days to get a USB setup working with this requirement.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1015 points

    Amit,

    Yes, please do try the setup.  I've double checked the USB 2.0 spec again - section 5.8.3 lists ZLP as one of three allowed conditions to signal bulk transfer complete.  Thank you.

    Regards,

    Yan

  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan,

    I checked the usb bulk device example first. The windows driver does not insert ZLP and must be done in the application that we have. This will take another cycle for me to get the application working.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1015 points

    Thanks for the update Amit.  The ZLP must be something mandatory in MTP.  I use Windows Explorer to transfer any file to a MTP capable device and I always see a ZLP packet if the transfer size (sile size + 16bytes header) is a multiple of 64. 

  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan,

    The USB example we have is a generic bulk class device. I tried setting the usb_bulk_example with the WinUsb_SetPipePolicy with SHORT_PACKET_TERMINATE set to TRUE so that I could generate the ZLP. However for some reason the ZLP is still not getting generated nor do I see much of a documentation on examples with SHORT_PACKET_TERMINATE on the web.

    I have started a stackoverflow report as well to see if I get some external help to resolve ZLP is a Generic Bulk Driver.

    Regards
    Amit
  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points

    Hello Yan

    Finally got the ZLP to work. The issue was with the driver file. Anyways, I ran my setup of the usb bulk example with ZLP (see attached snapshot from LeCroy). The ZLP is seen by the device and on subsequent IN request the device responds...

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Expert 1015 points
    Hi Amit. How about subsequent OUT requests?
  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan,

    Yes, they were working as well. I can capture another snapshot and show multiple OUT-IN-OUT-IN with ZLP tomorrow as I had limited time on the Protocol Analyzer today. The test I ran:

    OUT: 64 byte
    ZLP
    IN: 64 byte
    OUT: 64 byte
    OUT: 64 byte
    ZLP:
    IN: 64 byte
    IN: 64 byte
    OUT: 64 byte
    OUT: 64 byte
    OUT: 64 byte
    ZLP:
    IN: 64 byte
    IN: 64 byte
    IN: 64 byte

    The snapshot shown is the last set of OUT-ZLP-IN

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1015 points
    All right. Thank you Amit.
  • 0 in reply to Yan Li29
    Expert 1015 points
    I'll check my end to see why my code is not handling ZLP correctly.
  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan,

    If there is some other specific test you want me to run with the USB device bulk example, I should be able to run tomorrow (unless I need to change the application once again :-))

    Regards
    Amit
  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points

    Hello Yan

    Attached is the snapshot of 3 back-2-back transactions as mentioned earlier with ZLP

    Regards

    Amit

  • 0 in reply to Yan Li29
    TI__Guru**** 244380 points
    Hello Yan

    Were you able to review the last post for the ZLP packets for back 2 back transfers?
  • 0 in reply to Amit Ashara
    Expert 1015 points

    Amit, 

    Thanks for the data capture.  I'll have to create a small project and send it to you when I get a chance.  I have launchpads so I will port a small project to that platform

    Yan