• State
  • Locked Locked
  • Replies 17 replies
  • Subscribers 63 subscribers
  • Views 2365 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.

AM3359 with TPS65217B not powering off

Nikos Mouratidis
Intellectual 270 points
Other Parts Discussed in Thread: AM3359, TPS65217

Hello,

Our custom AM3359 board, using TPS65217B demonstrates the following strange behaviour: when the UART0 Tx pin is connected to a host's serial port, then power-off (software or via PMIC power button) works properly. If the Tx pin is not connected, the board power-cycles a few seconds after the power-off event. It seems that the connection of the Tx pin provides some adequate bleed off to allow voltage levels to drop during power-off. But we have not managed to identify the root cause of the issue. Any ideas would be appreciated.

We have the same behaviour in all kernels we have tried (ranging from 3.2.33 to 4.1.10). We are using SD card only, there is no Flash on the board.

Thank you.

Best regards,

Nikos

  • 0
    TI__Genius 10885 points
    Hi Nikos,

    On your board, is UART0_TX pin connected to the PMIC?
  • 0 in reply to Richard Solarski
    Intellectual 270 points

    Hi Richard,

    No, it is not. The UART0_TX pin is only connected from the AM3359 to a header, and from the header we connect to a USB-Serial port when needed. No other connection exists on the pin.

    Best regards,

    Nikos

  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    Hi Nikos,

    The TPS65217 will attempt to reboot if a valid start condition exists, what related test pins are available for the PMIC?

    Valid wake-up events are a falling push-button edge, a rising USB edge, or a rising AC edge. If any of these are occurring, and PWR_EN is still low, the device will shut down again after 5 seconds.

    Do any of these conditions occur when UART0_TX is disconnected, and do they go away when this connection is present?
  • 0 in reply to Richard Solarski
    Intellectual 270 points

    Hi Richard,

    We have not been able to identify any even that would wake up the PMIC and would be eliminated when UART0_TX is connected. The effect of the UART0_TX connection seems to be solely attributed to the electrical conditions it establishes when the pin is connected, there is no data exchange going on. It is as if there is the need to bleed off some current to popwer-off, and UART0_TX provides that.

    Please find attached the schematic of the design. Please note that we have tried removing C81 and grounding PMIC pin 12, as well as replacing C67 with 100nF, after the suggestions from the Sitara Processors Forum, but there was no change.AM3359_Board.pdf

    Best regards,

    Nikos

  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    Hi Nikos,

    How are you asserting the push-button low for >8s in both cases?

    If you artificially load UART0_TX and scope this pin can you confirm that this behavior is voltage dependent on this connection?
  • 0 in reply to Richard Solarski
    Intellectual 270 points
    Hi Richard,

    We have tried in two ways:
    1. We press the physical button, measuring time, while at the same time we monitor LEDs on the board that go off
    2. The board has a WiFi interface, so we ssh to it, and manually issue a poweroff command (Kernel support has been built-in).

    We cannot confirm the dependency on the UART0_TX pin, but we have been able to see one of the SD slot signals, which, when no UART pin is connected "insists" on remaining high (we even tried to pull it down) during power-off, while with the UART pin connected, the SD signal also drops.
  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    Hi Nikos,

    The PMIC should still shut down when the push-button is held down, can you confirm that this is occurring? If not, could there be an issue with J4?

    Are you removing just one wire (UART0_TX) or are your moving an entire connector?
  • 0 in reply to Richard Solarski
    Intellectual 270 points
    Hi Richard,

    Yes, the PMIC shuts down, and after an indeterminate number of seconds (usually 1-4) it comes up again. We simply connect or remove the UART0_TX wire and the behavior changes.
  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    Hi Nikos,

    If all rails come back up again, that means that the PMIC sees a valid start condition after shutting off, and if it stayed on for longer than 5 seconds it means that PWR_EN is asserted high.

    If UART0 is the culprit, there must be a feedback path somewhere to the PMIC logic connections, so is it possible to capture AC, PWR_EN and PB_IN with and without UART0 connected?
  • 0 in reply to Richard Solarski
    Intellectual 270 points

    Hello Richard,

    Please see below the waveforms for the two different cases, with the UART connected (uart_on) and unconnected (uart_off). Something seems strange on PB_IN in the second case, however, the connection of PB_IN from J4-1 is as shown in the third image.

    Yellow: AC
    Green: PWR_EN
    Purple: PB_IN

    uart_on: UART attached, power off successful

    uart_off: UART not attached, powers up on its own ~8s after power off

    Best regards,

    Nikos

  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    Hi Nikos,

    I see that you also have an external pull-up to VDD_3V3A, while there is also an internal pull-up for PB_IN to an Always-On LDO. I'm wondering if something on the 3V3A rail is pulling down your PB_IN voltage, which might be somehow supplemented by UART0_TX when it is present. Does removing R83 change the behavior at all?
  • 0 in reply to Richard Solarski
    Intellectual 270 points

    Hi Richard,

    Seems that you have put us on the right track: the button that is connected to PB_IN is also connected to a CPU GPIO (GPIO1_18). Removing R83 alone did not resolve the issue, the board starts to power-cycle indefinitely (obviously because of the GPIO); however, also cutting the GPIO link seems to have altered the behaviour of the system, and it now stays powered-off when connected to AC power. The issue however remains when connected to a battery: even without R83 and the GPIO connection, the board powers up again immediately after power-off.

  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    When BAT is the only supply, the PB_IN pin is the primary start event, so does this pin look any different operating from BAT vs. AC?

    Does the PMIC behave the same for both software and hardware shutdown events?
  • 0 in reply to Richard Solarski
    Intellectual 270 points

    It does not look that the PB_IN pin behaves differently between BAT and AC operation. Please see below two captures, one with AC and the other with BAT. In BAT operation, it seems that PWR_EN rises without any transition on PB_IN (the button is left right after the power-up was noticed).

    The behavior is the same for both software and hardware shutdown events.

    Yellow: AC
    Green: PWR_EN
    Purple: PB_IN

    AC powered: PWER_EN falls and remains low

    BAT Power: PWR_EN falls and then rises again 


  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    Hi Nikos,

    PWR_EN is an input only pin, so this means the PMIC_PWR_EN pin of the AM335x is somehow getting asserted.

    Does VLDO1 behave the same for battery and AC operation?
  • 0 in reply to Richard Solarski
    Intellectual 270 points

    Hello Richard,

    It seems I was mistaken in my previous mail, the software shutdown even was successful, the hardware event fails.

    Please find below the capture of the hardware event, in the AC and BAT power cases. For battery power, there are two graphs: one with the PB_IN button lifted as soon as PWR_EN goes down, the other with the button kept pressed, showing a repetition of powerup-poweroff cycles.

    Yellow: VLDO1
    Green: PWR_EN
    Purple: PB_IN

    AC power

    BAT, with PB_IN pressed until initial PWR_EN low

    BAT, with PB_IN pressed constantly

  • 0 in reply to Nikos Mouratidis
    TI__Genius 10885 points
    Hi Nikos,

    This means that something is asserting PWR_EN. The Sys rail will behave differently when BAT is present, so possibly investigate that rail for possible paths back to this pin?