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.

Problem with C5505 USB Endpoint 0 Multi-packet (e.g. size>64)

This is in regard to a secondary bootloader for C5505 (code updating via USB). I am using the v3.03 CSL for C5505. Our codeupdater PC application expects an HID Windows driver. We use the Set Report/Get Report requests for the command interface, with interrupt endpoints to transfer the data for the most part.

I am not using the HID CSL module, per se. I am using parts of the CCS 5.0 Intc example and the CSL  because we need to handle application-specific details outside of the CSL. The enumeration works correctly. The interrupt endpoint works fine transferring the file data from the Host to the Device (DSP) in chunks that are multiples of 64 bytes.

 

I am having a problem getting Set Report to work. The current protocol requires 80 bytes to be sent by the host. On an analyzer I see the 80 byte request split into two OUT tokens, first 64 bytes, then the remaining 16 bytes as it should. For some reason, the device (C5505) issues a STALL at that point instead of a Zero-length packet or ACK as expected. The host application will generally retry the Set Report (depending on the function it is performing), with the same result every time. (There may be a glitch in my ISR handling of the RX interrupt for data transfers vs SETUP packets.)

 

Similarly, Get Report must return 80 bytes to the Host. The Host does not follow with a Get Report because the Set Report had an error (so that is TBD).

 

Please let me know what is possible on this.

  • CSL HID module needs some changes to handle packets of length more than 64 bytes over EP0

    You can use the updated csl code attached in the below post.

    http://e2e.ti.com/support/dsp/c5000/f/109/p/341349/1195357.aspx#1195357

    - Pratap

  • Thanks Pratap. I need to modify my code to fully support this but the Set (Feature) Report sequence looks right and the Host did issue a Get (Feature) Report which is correct for our protocol.

    It did break some of the enumeration code (which relied on the way USB_clearEpRxPktRdy worked before)

    Stephen