• State Resolved
  • Replies 4 replies
  • Subscribers 103 subscribers
  • Views 130 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

DRA829J: Occasional USB drops. MCU_PORz doesn't help.

Bo Mellberg
Intellectual 361 points
Part Number: DRA829J
Other Parts Discussed in Thread: DRA829

Tool/software:

Hello experts,

We have seen occasional USB drop-outs on our devices after some run-time.

The USB is connected to USB0 and SERDES3 interface.

The strange thing is that even though we reboot in DFU mode (boot rom from USB) the device is
not visible to the host (dfu-util -l). We need to perform a complete power-off-on sequence to get
the device responsive over USB again.

Questions:

  1. Am I correct in that many register settings are surviving the MCU_PORz reset? If yes, is there a way to
    get the SoC completely reset by software, and not having to pull power?
  2. What registers might be involved in our USB setup and how come it becomes unresponsive even
    when booting in USB mode (boot rom)?

Best regards,

/Bo

  • 0
    TI__Guru*** 149290 points

    Hello,

    Assigned engineer is out of office. Please expect delay in response.

    - Keerthy

  • +1 in reply to Keerthy J
    TI__Mastermind 41930 points

    HI Bo,

    So far i haven't faced this issue on the EVM even after doing a warm reset . Are you able to reproduce the issue on EVM? The other way to do the reset is using pmic reset.

    Regards
    Diwakar

  • 0 in reply to Diwakar Dhyani
    Intellectual 361 points

    Hi Diwakar,

    Diwakar Dhyani said:
    So far i haven't faced this issue on the EVM even after doing a warm reset . Are you able to reproduce the issue on EVM? The other way to do the reset is using pmic reset.

    Thanks for your answer. I haven't tried it on the EVM since it is a rare symptom. As toggling power helps, we will implement a PMIC reset in parallel to the MCU_PORz to be sure to have a clean state upon boot.

    Regards,

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru 50612 points

    Customer follow-up summary ... 

    As described in the above  we did not get out of the "hanged" USB state even with a reset button press (read: MCU_PORz toggle). A full power cycle however made it work again. This problem was patched by implementing a PMIC reset(PMIC_EN toggling for TPS6594xx ) when pressing our "reset button" as per suggestion in above thread. The idea with PMIC was to mimic the full power cycle and it helped us to getting rid of the original USB "hang" issue.

     However, after a while we discovered that two out of our three ethernet ports stopped working after this PMIC reset change. When debugging this we discovered that the timing between power on, MCU_PORz and PMIC disable and enable can make the ethernet ports work or not work. 

    <snip>

    One central question is why the MCU_PORz reset is not enough for us to get out of the bad USB state. How can the platform stay in a certain state even though we toggle MCU_PORz?

    Follow up questions from TI-internal brainstorming: 

    • Can you share schematic (send via email or PM)?
    • Block diagram of PMIC + reset topology?
      • How is the board reset tree different from a pmic-only-reset tree?  Are some phy components or the like not hooked to both trees?
    • Timing diagram for enable sequences that work/don’t work?
    • Can issue be reproduced on EVM?
    • Can you summarize reset timing:  The board reset speed is probably 1/5x that of the PMICs sequence default.   Often when programming the PMIC the reset time can be stretched by a write via I2C/SPI to some PMIC config memory.   Giving more time might help.

    • On MCU_PORz assertion, you state the connected USB host does not detect the DRA829.  What does USB do to let host know device is connected?  (Likely VBUS does NOT toggle w/ MCU_PORz so maybe something in design.).  

    • Regarding the Ethernet ports – PHY likely has dedicated regulator NOT part of PMIC, so you should ensure the power sequence required by PHY is correct.

    • When assering MCU_PORz, how does MCU_PORz_OUT, PORz_OUT. MCU_RESETSTATz, and RESETSTATz behave? (is it the same, good vs bad)  à the goal is to see that mcu_porz is propagating through the MCU_PLLCTRL and to the MAIN domain (and through PLLCTRL in MAIN domain)
    • Can you check BOOTMODE signals, too. If these signals are not getting latched properly, the MCU_PORz could have been proper but the re-boot fail….

    Regards,

    Kyle