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

DIR Signal Stays Asserted

Jared Hagel
Prodigy 70 points

Other Parts Discussed in Thread: OMAP3503, TUSB1210, TUSB1211

I am using the TUSB1210 transceiver to connect to USB port 2 (HSUSB2) on the OMAP3503 processor. We find that occasionally after disconnecting and reconnecting a USB device from the transceiver that the transceiver can get into a state where:

  • The DIR signal becomes and remains asserted (high).
  • The CLOCK signal functions as before (60Mhz signal).
  • The STP signal becomes and remains de-asserted (low).

Because the DIR signal stays high the OMAP3503 processor can no longer communicate with the transceiver. We can return the transceiver to normal operation by temporarily asserting the RESETB signal.

We are looking for a way to return the transceiver to normal operation without using the RESETB signal.

The ULPI specification states that the USB transceiver will keep the DIR signal high in low power mode, Full Speed/Low Speed Serial Mode, and if the ULPI interface is not usable. According to the specification, asserting the STP signal should return the USB transceiver to normal operation in both low power and Full Speed/Low Speed Serial Modes. However, we found that when we use the alternate function of the STP signal on OMAP3503 to assert STP that the DIR signal becomes low for 10ns, high for 40ns, low for 10ns, high for 40ns and so on until we return STP to its normal function. After this STP goes low again and DIR goes high again.

Does anybody know why DIR would remain high even after STP is temporarily asserted? If the ULPI interface was not usable I would suspect that DIR would not go low at all, but it fluctuates between low and high when STP is asserted.

Thanks!

  • 0
    TI__Intellectual 2090 points

    Could you please describe how do you perform the disconnect (manual plug/unplug or SW)?

    We do not suspect that this reported issue is due to Host disconnect (since Host disconnect is directly covered by USB2.0, the Host stops sending SOF and after 3ms the remote Device times out and disconnects).
    Instead I suspect the disconnect issue reported  is some abrupt stopping of USB communication by software which leaves the Device PHY internal state-machine stuck waiting for an end-of-packet which never arrives.

  • 0 in reply to Fabian Stel
    Prodigy 70 points

    Thanks for the response Fabian. 

    We are manually plugging and unplugging a USB memory stick.

    A few other details:

    • The TUSB1210 is in host mode (DpPulldown and DmPulldown are both set to 1b).
    • As I wrote earlier, DIR remains asserted (high) when TUSB1210 gets into this problem state. We attempted to get out of this state by asserting the STP signal. Asserting STP did not work. I've attached a snapshot of the DIR signal when we asserted STP for about 32us - zoomedout.png. This snapshot shows DIR begins high, then toggles while STP is high, and finally remains high when STP goes low again.
    • I've also attached a zoomed in snapshot of the DIR signal while it is toggling – zoomedin.png.

    If the PHY is waiting for an end-of-packet which is not arriving, could we send an end-of-packet to get out of this state? Could we send this packet using USB port 2 (HSUSB2) signals?

    Thank you.

    zoomedout.png:

    zoomedin.png:

  • 0 in reply to Jared Hagel
    TI__Intellectual 2090 points

    We do not suspect that this reported issue is due to Host disconnect (since Host disconnect is directly covered by USB2.0, the Host stops sending SOF and after 3ms the remote Device times out and disconnects). Instead, we suspect the disconnect issue reported is some abrupt stopping of USB communication by software which leaves the Device PHY internal state-machine stuck waiting for an end-of-packet which never arrives.

     We would also provide the customer with the recommended method for a Device to disconnect correctly: 

    • Software disconnect: (SW decides it no longer wishes to do USB communication while in the middle of USB transactions)

      –         SW should insert a register write to FUNC_CTRL with bits(1:0) XCXRSELECT = “01” and bit5 RESET=1
      –         Then the Device controller run/stop bit should be toggled (in the apps. processor/USB controller chip).
      –         This will assert a UTMI reset (FUNC_CTRL bit5) at the same time as setting FS to reset internal PHY logic which will prevent the PHY from hanging before toggling the device controller run/stop
      –         Note that UTMI reset is automatically cleared by the PHY
       
    • Physical Unplug Usecases: (disconnect due to device unplug Scenarios when TUSB1210/TUSB1211 is acting as a Device)

      –         Plug or cable disconnects from Host, all pins disconnect
    • If the PHY was in RX mode at time of unplug it is possible it may hang since it never sees end-of-packet
    • We expect the PHY will detect the erroneous state of DP/DM pins and will continue to send RXCMDs to the device controller
    • Since RXCMD contains VBUS presence information (Bits3:2) the device link controller should be able to detect VBUS disconnect and gracefully reset/power down link controller & TUSB121x

               –         Plug or cable disconnects from Host, DP/DM disconnects, VBUS remains

      • RXCMDs will not show VBUS disconnect
      • We recommend Driver or SW uses a timer to detect lack of USB activity/response, and then SW should assert TUSB121x RESET_N pin for 200ns min to gracefully exit HS mode
  • 0 in reply to Fabian Stel
    Prodigy 70 points

    Thank you Fabian.

    Based on the voltage levels of the data signals it seems the TUSB1210 transceiver is hung waiting for an end-of-packet which it never receives.

    Measuring voltages on the data signals of TUSB1210 show the following. Note that in this problem state these voltages do not change. I assume this means that the transceiver is sending the same Receive Command Byte (RX CMD) over and over again.
    D7 D6 D5 D4 D3 D2 D1 D0
    0 0 0 1 1 1 0 0

    According to the ULPI specification, this means:

    • Bits5:4 = 01 = RxActive
    • Bits3:2 = 11 = indicate VbusValid
    In this state you recommend asserting the TUSB121x RESET_N pin for 200ns. We did this, and the PHY becomes operational again. However, the PHY configuration registers are modified after the reset. I've attached the before and after levels of the PHY registers. before.txt shows the registers when the PHY is functional. after.txt shows the registers after the reset.

    I have 2 questions about this.
    • Should I be concerned about these differences in register contents?
    • If so, how should they be modified?
    Thank you!
  • 0 in reply to Jared Hagel
    TI__Intellectual 2090 points

    Functional. after.txt is showing value after the reset meaning that the device come back in is default state.

     

  • 0 in reply to Fabian Stel
    Prodigy 70 points

    Hi Fabian. Is it OK to leave the PHY in its default state, or should the PHY be manually configured so it matches 6712.before.txt? If so, should the PHY be configured using the OMAP INSNREG05_ULPI register or using OMAP registers within the HSUSB ULPI register space (ie. registers at addresses 0x48062800 to 0x4806283F)?

    Thanks again!