DIR Signal Stays Asserted

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.

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:

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

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.

According to the ULPI specification, this means:

• Bits5:4 = 01 = RxActive
• Bits3:2 = 11 = indicate VbusValid

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

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!