• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 434 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.

USB TLL module access.

DavidVescovi
Genius 5470 points
Other Parts Discussed in Thread: SYSCONFIG

I am seeing an issue with the USBTLL module as part of the HS USB host driver initialization.

 I am occasionally getting an exception thrown when I try to do the soft reset of the USB TLL. I have narrowed it down to when the USBTLL_SYSCONFIG register is accessed.

I am using a 3503 device  BSP 6.15 or 6.14.2 with some modifications on a custom board.

We are using a SMSC3320 PHY but we are NOT doing suspend/resume so I do not believe it is related to the PHY (as has been documented in the advisories) also the exception occurs way BEFORE any access to the PHY takes place.

Usually the exceptions occur when the F/I clock to the module is not initialized but I can see, with the help of the "do" test utility the TLL clocks are indeed initialized. i.e.:

USBTLL    Enabled(1), AutoIdle(1)

120M_FCLK(1)

-DPLL5_CLKOUT_M2(1)

--DPLL5(1)

---VDD5(1)

Another strange thing is it is not consistent. It is very random and only occurs occasionally.

I have found when it gets into this mode I cannot get it out. I tried using  the "do" to disable and then re-enable the module with "do device disable USBTLL" and then a "do device enable USBTLL".

And then "do inreg32 48062010" which should read the config register but it still throws the exception.

When it does come up correctly I have no problem reading the config register or disabling it (which will then throw the exception if register is read as expected) and re-enabling it (which the register then reads ok as expected).

Can anyone shed some light on the

  • 0
    TI__Genius 9185 points

    David: Here is the feedback from an engineer who is somewhat familiar with the EHCI driver. I understand that you are not doing suspend/resume but still the information below maybe useful and may give you some pointers.

    "This is similar to a problem that I was seeing where the USB TLL block clocks was stuck in idle mode after suspend/resume (the ST_USBTLL bit stays low in the CM_IDLEST3_CORE register even though the USB TLL ICLK enable bit is active).

    Changes were made to the TI_EVM3530 CE6 BSP EHCI driver to fix this problem by enabling the SAR (Save And Restore) mechanism for the USBHOST and the USBTLL blocks. When the clocks are disabled, the domain may go to the OFF mode causing the USBTLL logic and register contents to become corrupted unless the SAR is enabled. Other changes were made to the UHHC_SYSCONFIG register idle and wake up bits. Recommend you study the TI_EVM3530 CE6 BSP EHCI driver from BSP 6.14.1/BSP 6.15 for guidance."