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

Original question:

PROCESSOR-SDK-OMAPL138: OHCI Host Controller does not send ACK for first Data Packet Received after Remote Wakeup - omap...

PROCESSOR-SDK-OMAPL138: OHCI Host Controller does not send ACK for first Data Packet Received after Remote Wakeup

H@fiz
Intellectual 440 points
Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: OMAPL138

Hi, 

We are working on USB Host Suspend, Resume and Remote Wakeup feature on OHCI controller (omapl138evm). 

When USB Bus is resumed via software control, it is resumed and works correctly but when USB Bus is resumed via Remote Wakeup, first IN transaction is not completed. i.e. Host sends the IN token. Device sends the data in response but Host does not send an ACK. USB Analyzer shows that there is turn-arond/timeout error. Then Host sends the IN token again. This time same previous data (first transaction data) is received and Host acknowledges the device. After the first transaction (in which ACK is missing), all IN transactions works correctly.

It is observed that OHCI controller is not getting Data interrupt along with Remote Wakeup Interrupt. When device is resumed via remote wakeup, only the remote wake up interrupt is received by OHCI hardware. Write Done Head interrupt is not generated which is essential for data transfer. Since No interrupt is generated so Host controller does not take any action. At the same time, it should be noted that Data is NOT lost. Device sends the same data again and Host sends the ACK after successfully receives the data. 

It seems, when both Remote Wakeup and Data Interrupts comes together, then Host hardware IGNORES data interrupt and only processes the Remote Wakeup interrupt. This seems logical because Host is suspended at that time and can’t process data packet.

Observations

  • If during Remote Wakeup, Device only sends the remote wake up event (interrupt) but don’t send data then timeout/turn-around is NOT appeared on USB Analyzer. It is verified using HID class (Standard Mouse Device).
  • If during Remote Wakeup, Device sends the remote wake up event and after some duration, sends the data, then timeout/turn-around is NOT appeared on USB Analyzer. It is verified using HID class (Standard Mouse Device).
  • If during Remote Wakeup, Device sends the remote wake up event and data packet together (very close to each other OR simultaneously) then timeout/turn-around is appeared on USB Analyzer. It is verified using CDC class (Standard Cable Modem Device) and HID Keyboard device.

  • Though timeout transaction is visible on USB Bus but no interrupt is received by Host against this packet.
  • OHCI Controller has no record of this transaction. No interrupt is received by Host Controller against this packet. Since this is not a transaction so no Error is observed in OHCI Controller state machine and in its Transfer Descriptor. Second transaction (on USB Analyzer but first for Controller) works correctly and OHCI Controller completes the transaction without any error reporting. Please note that Error Count (EC) is zero in General Transfer Descriptor of OHCI and hence HOST Controller does not report an error condition code in General Transfer Descriptor.
  • Upon failure of ACK against first IN Packet, Host immediately (within ~13 Micro Seconds) sends an IN Token (second). Device sends the previous data packet again. Finally, HOST sends the ACK to Device.

Any reason, why Host does not ACK first transaction? 

Regards 

  • 0
    TI__Guru**** 171091 points

    Hi,

    What software and version do you run on OMAPL138? When the device send remote wakeup signal, is the OMAPL138 in standby mode or only the USB bus is in suspend mode?

    I am not sure what causes the Host doesn't ACK the first transaction, but I can tell that afterward the device resend the data packet again then the host ACK'd it, this sequence follows the USB2.0 Specs, and the transaction is complete.

  • 0 in reply to Bin Liu
    Intellectual 440 points

    Hi Bin Liu,

    We are using RTOS for omapl138evm.

    When remote wake up event is sent, only USB Host Bus (OHCI) is in suspended mode.

    Infact, problem is started when Host does not get data interrupt along with remote wakeup interrupt OR data interrupt is received but ignored by Host Controller because Host is suspended at that time. Host controller software wake up the controller but since there is no data interrupt so no ACK is sent (but data is on the bus). Second time, device sends the data, Host receives the interrupt and sends the ACK after receiving of data.

    Regards

  • 0 in reply to H@fiz
    TI__Guru**** 171091 points

    Hi,

    H@fiz said:
    Host controller software wake up the controller but since there is no data interrupt so no ACK is sent (but data is on the bus).

    This is not how it works - it is not the data interrupt triggers the ACK, but the other way around.

    When the USB controller/PHY received a USB packet, the controller automatically ACK'd it based on the protocol defined in the USB 2.0 Specs, then triggers an interrupt for software to handle the USB packet.

    If for whatever reason (by electrical or protocol such as CRC error or timing) the controller cannot see or cannot recognize the USB packet, it won't ACK, then the other end (the USB device in this case) will re-send the same USB packet. This flow is defined in the USB 2.0 Specs.

  • 0 in reply to Bin Liu
    Intellectual 440 points

    Yes, This is as per USB Specs. Application, USB Host Stack/Middleware and OHCI controller are stable and we don't see any other issue except the waste of some micro seconds when there is no ACK for first transaction after Remote Wakeup.

    We are curious why there is no ACK from OHCI for first transaction after Remote Wakeup.

    Regards  

  • 0 in reply to H@fiz
    TI__Guru**** 171091 points

    Hi,

    The USB controller doesn't ACK basically means it cannot identify the USB packet. It could be caused by multiple reasons, such as noise on the USB bus. But the extra few microseconds shouldn't be a concern, unless the USB does suspend/resume much more frequently, for example, in every hundreds of microseconds, which is not a typical case.