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.

Linux/AM3358: USB OTG VBUS probing resets board

Part Number: AM3358
Other Parts Discussed in Thread: TPD4S214

Tool/software: Linux

Hi All

We have a custom board loosely based on the BBB.  AM3358, TPS65217C PMIC, etc.  This particular device can remain in a situation where it is expected to be powered for days at a time with several suspend/resume cycles.  All this is working as expected, however we are experiencing random running resets.  These can happen after hours of uptime, or as frequently as 30 minutes across multiple devices.

This board can be powered from a vehicle, 12V to a 5V switcher to the AC input of the PMIC and also from USB when connected to a PC.  There are situations where both will be present, or only one.  The resets DO NOT happen when USB VBUS is present.

I had added code to dump the reset status register upon starting our application and all of the data captured is for a cold power on reset.

Instrumenting a board I was able to capture several instances of the following:

Channel 1 is the SYS_5V out of the PMIC

Channel 2 is USB input to PMIC

Channel 3 is AC input to PMIC

This was done with USB disconnected from the board, and powered via a bench supply at 14V feeding out 5V switcher.

configuring USB0 as peripheral only has made the resets disappear for the most part, but we would like the actually use OTG.  We have a TPD4S214 in place to handle VUSB switching when acting as a host, and the functionality is working.

A side effect of turning off OTG we are no longer able to hot plug with a PC.  I know we can add software to do it manually, but it worked and I would rather not :)

We're not on a TI kernel, but this does not seem to be kernel related as it's the PMIC that is bringing the system down.

I have found several reports of this happening, that's how I ended up where I am.  I'm looking for a possible solution beyond turning it off.

Matt

  • Hi Matt,

    How are you handling the role switching to the SoC? AM335x doesn't support OTG, but does support Dual-Role mode in which the mode (Host or Peripheral) is determined by the state of the USBn_ID pin.

  • Hi Dave

    I guess we're using the Dual role then.

    The switch over is being handled via the USB0_ID pin.  It is left floating, unless a mini B to A OTG adapter is plugged in grounding the ID pin.  The TPS4S214 is being controlled with USB0_DRVVBUS to apply VUSB in the case of host mode.

  • Hi Matt,
    I'm not aware of a way to turn off the VBUS pulsing as part of OTG SRP (Session Request Protocol) and still have Dual-Role functionality. SRP is disabled when the USB controller is configured as dedicated Host or dedicated Peripheral, but that won't help your use-case.

    I've reached out to our SW resource to see if he knows a way to override SRP. I'll let you know what he comes back with.
  • Matt,
    I did receive verification that SRP pulsing cannot be disabled while retaining DRD functionality.

    At this point it makes sense to me to have the PMIC group look into this so I'll move this to their forum rather than have you repost there.
  • Thanks DK, I've looped in the expert on this device.

    Matt, can you confirm how nRESET and BATT are connected in this design?

    Best Regards,
    Rick S.
  • they're both floating similar to the BBB reference design.

    I can try them is different configurations if you'd like me to test anything.

  • Thanks Dave,



    If we continue forward with the peripheral only configuration, who may know if there is any way aside from creating some new software (driver or daemon to watch the USB present bit within the PMIC) to force the USB to enumerate? This functionality is obviously tied to the probing in some way.



    Creating the software is not the issue, but I don't want to reinvent if i don't have to.



    Matt
  • Matt,

    No battery in your system?

    One of 3 things is happening here:

    • PWR_EN pin going low unexpectedly
    • PB_IN pressed for > 8s || nRESET toggled low briefly
    • PPATH hand-off causing a Fault (AC to USB switch-over)

    If 1 or 2 is happening, then you can fix it easily without my help.

    If 3 is happening, it is because there is no battery in the system. Check that BAT_SENSE is shorted to BAT first, then remove any capacitance on the BAT pin and replace it with a 1-10k resistor to GND. Then re-test and tell me what you see.

  • Hi Brian

    the PB_IN is connected to a button, which I know that is not being pressed.

    I was capturing PWR_EN on some of my instrumented tests, along with the battery terminal.  PWR_ER was falling about 260 us after SYS_5V.

    I know BAT_SENSE is not connected to BAT, I will make that connection and retest.  We may need to run with this configuration until we have a slot to rev the PCB if this is the issue.  I will setup the test and report back.

    Channel 1  - SYS_5V

    Channel 2 - USB IN

    Channel 3 - PWR_EN

    Channel 4 - VBAT IN

  • Matt,

    It is clear to me there is a spike on BAT when you zoom in on the timing between SYS & PWR_EN.
    It is unclear to me if there is a spike on BAT every time the USB power glitches or if there is only a spike when SYS drops.

    Can you zoom in on an area where USB is falling from it's peak value and SYS does not drop, so that I can see the BAT pin voltage?
  • I will capture another event, but in the past BAT only spiked when SYS dropped. Do you want me to short BAT_SENSE and BAT for this or run like I was before?

    BAT sits slightly negative when it operates normally, I believe that is a fixed current sink looking for a battery?
  • Matt,

    I hope you are not waiting on me to reply to run some more tests.

    It would be best if you test 3 ways:
    1) Same setup as before
    2) Short BAT_SENSE to BAT and test again
    3) Pull BAT & BAT_SENSE (shorted) to GND with a 1-10k resistor and test again

    It should not matter if BAT is slightly negative during operation. I am more concerned with when BAT goes high because there isn't a battery in the system.