TPS65217 PB_IN pin functionality

Suresha,

According to the BBB schematic I’m looking at, S1 is the PB associated with the AM335x (RESET). S3 is the PB associated with the PMIC, try pressing that one, and see if you get a different result.

Janice

Janice,

Sorry for the confusion. 

I mistakenly mentioned switch S1 in the earlier post. We had pressed S3 only.

Thanks,

Suresha

Suresha,

Make sure the PWR_EN pin is being pulled high within 5 seconds, if not it will time out and send the part into OFF mode instead of active. Janice 

Hi Janice,

Thanks for your response.

We have probed for different voltages during this use case. Below are the observations.

1) When the board is functional, output voltages of all LDOs & DC-DC regulators of the PMIC will be proper. PMIC_POWER_EN will be high.

2) When PB_IN switch is pressed, PB_IN signal becomes LOW. During this time all the LDOs & DC-DC regulators output will  be proper. PMIC_POWER_EN will be high.

3) When PB_IN is held low for 8 secs,  all LDO's & DC-DC regulators go OFF. Also, PMIC_PWR_EN will be low. After this state, even the always on power supply , VRTC will not come up. 

Since VRTC itself is not coming up, we think that PMIC_POWER_EN delay is not the reason for board powering OFF.

Can you please confirm us whether this is the expected behavior ? 

Looking forward to your response.

Thanks,

Suresha N S

Suresha,

What is the state of the nRESET pin? 

When the nRESET pin is pulled low, all power rails, including LDO1 (VRTC supply) and LDO2 are powered down and default
register settings are restored. The device will remain powered down as long as the nRESET pin is held low but
for a minimum of 1 second. Once the nRESET pin is pulled high the device enters ACTIVE mode and the default
power-up sequence will execute. 

If the PB_IN pin is kept low for an extended amount of time, the device will continue to cycle
between ACTIVE and RESET state, entering RESET every 8 s.

Janice 

Janice,

We have tested the nRESET pin functionality & it is working as you have explained.

But during PB_IN testing the nRESET pin was always HIGH. We pressed the PB_IN switch continuously & board powered OFF after 8 secs.

We have tested this on Beaglebone Black & one custom board. We observed same behaviour on both the boards.

We are unable to find out of any reason for this behaviour. Can you please suggest us some method to conclude on this issue ?

Thanks,

Suresha  N S

Suresha,

It would be helpful to provide scope shots of the following during your test:

1. PB_IN

2. nRESET

3. PWR_EN

In the wait power enable state the only resource that should be on is LDO1. All other rails are off, while waiting for a wakeup event during the 5s.

Janice

Janice,

Please find the snapshot of the signals below :

After 8 secs of PB_IN press, nRESET will remain at 3.3V & PWR_EN at 0V.  These signals will return to earlier state after next falling edge of PB_IN.

Thanks,

Suresha N S

Suresha N S said:

Can somebody please clarify the functionality of PB_IN pin of TPS65217 ? Is the functionality is power cycle or power off ?

On my BeagleBones it power cycles, but I recall I've also witnessed the power-off behaviour so it appears to be dependent on configuration of the PMIC and/or RTC. I'm trying to reproduce a configuration in which it powers off, but without success so far.

Since I'm seeing the power-cycle behaviour if boot is interrupted (when u-boot says "Hit any key to stop autoboot" on the console), this would suggest the kernel is somehow responsible. Which kernel are you using exactly?

The 6.2ms between reset assertion (start of powerdown sequencer) and PWR_EN going low is also strange. Based on documentation, the only reasons for PWR_EN going low would be a scheduled shutdown (rtc alarm2), or the vrtc supply (LDO1) being cut. However, during a normal sequenced shutdown there should be 11ms between reset assertion (PGOOD low) and LDO1 shutdown.

Two possibilities that come to mind:

1. The RTC for some reason decides to drive PWR_EN low, and this perhaps preempts the reset-sequence and causes the PMIC to enter OFF-state instead. I see no reason why the RTC would do this (a scheduled shutdown makes no sense here) nor would I expect the PMIC to care about PWR_EN while performing a reset, but who knows.

2. A fault occurs during the shutdown sequence, causing LDO1 to be cut prematurely (hence PWR_EN goes low) and OFF-state to be entered.

The odd thing is that the power-off behaviour is actually documented in the BeagleBone Black System Reference Manual:

If you hold the button down longer than 8 seconds, the board will power off if you release the button when the power LED turns off. If you continue to hold it, the board will power back up completing a power cycle.

This suggests this behaviour is somehow supposed to be triggered on purpose. I'm not sure how though...

OK, this is getting weirder and weirder...

I've installed linux-image-3.14.42-ti-r64 and now the power button indeed exhibits the behaviour documented by the BBB SRM: if the power button is held until the power led turns off, the board powers off. Holding it a second longer will cause the system to boot again.

If I perform an external reset after the system has booted and halt it in u-boot, then perform a software cold reset via PRCM and halt again in u-boot, long-pressing the power button still causes power-off, indicating this behaviour is the result of some cold-reset-insensitive configuration performed by the kernel.

I've dumped the PMIC registers via I²C, but they had the same values as before. I've dumped the RTC registers: RTC is enabled, idlemode is set to 3, all other config has reset-default values. Just to be paranoid I also dumped the rtc-related PRCM and padconf registers, but nothing unusual there either.

After power-cycling the system and recreating exactly the same RTC configuration, and double-checking all other aforementioned registers had the same values as before.... long-pressing the power button causes the system to power-cycle, no power-off.

(Updated to indicate the behaviour is not just warm- but also cold-reset-insensitive)

Matthijs van Duin said:

2. A fault occurs during the shutdown sequence, causing LDO1 to be cut prematurely (hence PWR_EN goes low) and OFF-state to be entered.

I'm getting more and more convinced that this is precisely what is happening: the TI kernel causes increased power consumption (probably due to the HDMI framer, which my usual kernel doesn't enable and which is reset-insensitive) and this, combined with the mess at shutdown, triggers a fault condition hence entry into OFF-mode.

Whoever wrote that paragraph in the BBB SRM probably didn't realize this was abnormal behaviour.

If I set the INSTDWN bit in the SEQ6 register, thus removing any window during which a fault condition can be triggered, long-pressing the power button always power-cycles the system instead of entering power-off.

Hi all,

We have designed a new board with the requirement of powering OFF of the board when PB_IN switch is pressed for more than 8secs.
But with the same SW as that of BBB, we are observing a reboot condition instead of power-off in the custom board.

Only major difference is that in the custom board PMIC is powered ON using the battery input pins rather than the AC or USB lines. 
This looks to be the reason for reboot, as we tested the BBB with battery wired up to PMIC & observed the same reboot condition. 

Looking at the the TPS65217 state diagram, it looks that power cycle is the expected behavior when PB_IN is pressed for more than 8secs. 
In case of  poweroff condition observed in BBB, PMIC might be entering the fault condition due to which power cycle is not happening.
We also tried setting the INSTDWN bit of PMIC to skip the powerdown sequence & observed that the BBB is rebooting instead of powering OFF.

We think that only condition power-off happens is when the power-down sequence is not followed properly.  
In case of AC or USB powered PMIC, VSYS voltage is cut down when PPM gets disabled during power-off.
Due to insufficient voltage at VSYS pin, PMIC will not be able to complete the power down sequence properly.

By Setting INSTDWN bit of PMIC, we are bypassing the power down sequence. Thus the fault condition never occurs.
Also, when battery is connected, voltage at VSYS will be present even though PPM is disabled.
This results in proper power-down sequence which in turn results in board reboot. 

Is our understanding correct ? Please confirm.

Also, since our requirement is to poweroff the board when PB_IN is pressed for more than 8 secs, can you suggest an alternate method to achieve this ?
As mentioned earlier, we are powering on the PMIC from battery input pin & both AC,USB pins are not connected to power supply.

Looking forward to support.

Thanks,
Suresha N S

Please post this question on the PMU forum: https://e2e.ti.com/support/power_management/pmu/f/200

clamp.xpsSuresha,

As long as PWR_EN is pulled high once the device exits RESET state board will reboot and enter ACTIVE state, not power down and go to OFF state. If PWR_EN is pulled low once out of RESET state the device will wait 1s and move to OFF state. If you think that the power sequence isn't being followed properly, try this clamp circuit to ensure the proper power down is being followed.

Let me know if this helps.

Janice

Your understanding is correct.  Since at the beginning of shutdown (including power-cycling) the PMIC unconditionally switches to battery power, even if no battery is present, the system runs on capacitors during the powerdown sequencing and depending on current consumption this may cause the power supplies to fail prematurely and the PMIC enters FAULT state, effectively causing the device to switch off.

On a plain BBB the behaviour depends entirely on the HDMI framer: PGOOD goes low at start of the powerdown sequence, thereby putting the AM335x and the Ethernet PHY into reset, which cuts most power consumption. The HDMI framer is oblivious to reset, hence if it is enabled then it will continue to draw considerable current during shutdown and triggers a fault. If the HDMI framer is disabled, the fault is avoided and a BBB will also power-cycle rather than power-down.

See here for some scope pics of various powerdown scenarios.

Beware that BBB rev A6A or later do not support battery-powered operation: the 3V3B regulator remains on during and after shutdown. On battery power it will remain on indefinitely, while the rest of the supplies are off, which is a very bad thing. Since the console buffer IC is powered by the 3V3B, you must especially avoid driving the console RxD high, since this will cause heavy current injection into the UART0_RXD pin of the AM335x. See this forum post and its follow-ups for a detailed explanation of the problems.

(Note also that all versions of beaglebone have issues with power supply timing: on BBB prior to rev A6A there is a 1ms window during power-up and power-down where 3V3B is powered but 3V3A is not. BBB rev A6A and all versions of BBW have okay power-up but leave the 3V3B enabled for way too long during power-down. This especially means that reboots while having a console cable connected may strain the UART0_RXD pin, and I've already seen three reports of where a BBB console RxD started suffering from mysterious problems or died altogether after long-time use. External CAPEs which drive BBB pins to 3V3B would cause similar problems.)

Hi ,

Thanks for the detailed response.

Unfortunately, we have designed a board with the requirement of powering OFF when PB_IN switch is pressed for more than 8 secs.
We had tested this on BBB & since power off was working, we went ahead with the design.
But in our design, PMIC is powered ON from the battery input rather than the USB/AC inputs.

Do you think we can achieve the required power-off with the existing design ?
Is there any proper method to shutdown the PMIC after 8 secs press of PB_IN switch ?

Please suggest.

Thanks,
Suresha  

It is indeed unfortunate that the BBB System Reference Manual makes it seem like the power-off behaviour is normal. Most likely whoever wrote it did not realize it was abnormal behaviour caused by a power management fault.

I haven't checked, but it may be possible to distinguish this situation from a normal power-on by inspecting PMIC registers. If so, the early bootloader could detect this and immediately proceed to perform a shutdown.

Performing a shutdown is not entirely trivial, since this can only be initiated by alarm2 of the RTC. A sequence of U-Boot commands that performs it is:

# set OFF bit
i2c mw 24 0a 80

# unlock rtc registers
mw.l 44e3e06c 83e70b13 1
mw.l 44e3e070 95a4f1e0 1

# halt rtc
mw.l 44e3e040 00 1

# dump pmic registers (for debugging)
# (also acts as a delay to ensure rtc is halted)
i2c md 24 00 20

# disable and clear irqs
mw.l 44e3e048 00 1
mw.l 44e3e044 ff 1

# configure rtc-based power control, clear wakeup
mw.l 44e3e098 0001f011 1

# init rtc clock and alarm2 registers
mw.l 44e3e000 01 7
mw.l 44e3e080 01 6

# schedule alarm2 in 1 second
mw.l 44e3e080 02 1

# enable alarm2
mw.l 44e3e048 10 1

# enable rtc
mw.l 44e3e040 01 1

This procedure was designed to be robust with the RTC in unknown state. In your case you'd know the RTC is still halted with clock/alarm/irq registers in reset state, and I think u-boot already unlocks the registers since it keeps a boot-attempt-counter there, so then most steps can be omitted. Do be sure to set the OFF bit in the PMIC before using the RTC to trigger powerdown, since otherwise you'd enter "RTC-only mode" which is not supported by the BBB (except some early hardware revisions).

BTW, I hope this is not intended to be a normal way to power down your device, unless the eMMC is used purely read-only (or not at all), considering that cutting power to eMMC (or even merely resetting it) while writes may be progress leads to data corruption sooner or later.