• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 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.

TAS1020B and powered USB hubs

Shawn O'Connor
Prodigy 10 points

On a design using the TAS1020B, I have run into an issue where an unusual number of NAKs are encountered when the TAS1020B is sending the TX data for a FeatureReport. This only happens when the device is connected through a powered USB 2.0 hub. The result is that HID GetFeatureReport takes a long time to respond on the PC.

I believe the issue is with the ROM handler for the HID requests. After my application sets the data pointer for the HID report data and returns back to the ROM, the ROM code appears to be accessing the return data twice. Once for copying the data pointer, and the second to set the UsbRequest status.

Usbhid.c:

 

UsbRequest.dataPtr = DEV_DATA_PTR;

UsbRequest.status = DEV_DATA_BYTE;

The problem is that both lines are accessing the same union. Pointers are apparently stored as three byte in Keil, with the first byte representing the memory space. 0x00 is DATA, 0x01 is XDATA and 0xFF is IDATA. Anyways, I am passing in an XDATA pointer so the first byte of the pointer is always 0x01. When reading DEV_DATA_BYTE is it essentially reading the first param byte which will always be 1. This means that the UsbRequest.status is always equal to EVENT_ERROR and I presume the ROM behavior is to NAK.

The part I don't understand is why I only see NAKs when connected through a powered hub. Regardless, this seems to be a pretty serious issue. I am referencing the code in the ROM folder of TAS1020B FDK which i assume matches the ROM implementation.

 

 

 

  • 0
    TI__Expert 4160 points

    Shawn,

     

    I agree that the ROM code should not have made the ‘out’ element of DEV_FUNC_PARAM a ‘union’.  The effect is to conflate DEV_DATA_PTR and DEV_DATA_BYTE, so that hidHandler() can’t really indicate success/failure independent of the return data pointer. 

     

    As a suggestion, in your registered handler for DEV_HIDGETREPORT, could you setup the UsbRequest.dataPtr and UsbRequest.status yourself, pop the return address from the stack, and long jump to the instruction that returns from hidHandler().  The intent would be to skip-over the

        UsbRequest.dataPtr = DEV_DATA_PTR;

        UsbRequest.status = DEV_DATA_BYTE;

    code.  I realize this isn’t a solution that would be ‘portable’ to different ROM versions, but I’ve been told that there will not be any updates to the TAS1020.

     

    Alternatively, I guess you _could_ have your response data in ‘data’, so that the first byte would be 0?

     

    [I’m currently going through some problems with my Keil tools associated with upgrading to a Windows 7 64-bit PC, so I can’t check this approach at the moment.]

     

    If this fix is not sufficient to resolve the problem, it could be that a problem encountered by another TAS1020B user is the culprit.  This problem appeared when the host sent the TAS1020B application a custom control transaction having more than 8 bytes, which the endpoint should have stalled.  Instead, the endpoint cleared the NAK bit early.  In usbeng.c, engSaveRxFifo invokes ZEROPACKInEp0, which clears the NAK bit (but this is only invoked if EngParms.event == USB_WRITE_EVENT in engEp0RxDone, which doesn’t sound exactly like your case). To fix this, a ‘ROM patch’ was required;  the customer eventually discarded the ROM patch, since he had insufficient code RAM space for it.

     

    Do you actually have a USB trace (i.e., capture via sniffer) that shows the problem?

     

    Regards,

    Frank