Safely power down the PocketBeagle supplied by a battery

Hello all,

I am using a PocketBeagle supplied only by a single cell LiPo. It powers up normally after pressing the power button.
When I want to shut it down, I press once on the same button and it starts to shut down. In the end, the PWR LED and the USR2 LED are on and stay on (steady light).

When pressing the Power button for 10s, all the LEDs (PWR and USR0 to USR3) turn off and then (after 1s) the PWR LED turns on automatically followed by the other USR LEDs and the PocketBeagle powers up again. (Compared to when only supplied through USB (no battery), all the LEDs turn off and stay off unless I press the power button to power it up).

My questions are:

  1. Is the Pocketbeagle considered to be turned off properly at this stage when PWR LED and the USR2 LED stay on after pressing once the power button? (The voltage rails are still high.)
  2. Is this a normal behavior? And does it have something to do with the clamping circuit discussed here?
  3. If not, how can I fix it (HW or SW solution)? I want the Pocketbeagle to safely power down when I once press the power button.
  4. I think there is no way to get the voltage rails to 0V due to the 3.3V bug. But, is it safe to always disconnect the battery in that state (PWR LED and USR2 LED are on after pressing the PWR button to shut the PocketBeagle down)?

I am using the Stretch IoT Debian 9.4 version.

Thanks

Hello all,

I am using a PocketBeagle supplied only by a single cell LiPo. It powers up normally after pressing the power button.
When I want to shut it down, I press once on the same button and it starts to shut down. In the end, the PWR LED and the USR2 LED are on and stay on (steady light).

Can you capture a serial log? In my experience, it shuts down fine.

When pressing the Power button for 10s, all the LEDs (PWR and USR0 to USR3) turn off and then (after 1s) the PWR LED turns on automatically followed by the other USR LEDs and the PocketBeagle powers up again. (Compared to when only supplied through USB (no battery), all the LEDs turn off and stay off unless I press the power button to power it up).

It is hard to catch the window of where it would stay off without doing the software power down.

My questions are:

  1. Is the Pocketbeagle considered to be turned off properly at this stage when PWR LED and the USR2 LED stay on after pressing once the power button? (The voltage rails are still high.)

No.

  1. Is this a normal behavior? And does it have something to do with the clamping circuit discussed here?

No. No. Something happened with the kernel during shutdown. Capture the log. One of the services or drivers didn’t shut down properly. The PMIC should have been powered off.

  1. If not, how can I fix it (HW or SW solution)? I want the Pocketbeagle to safely power down when I once press the power button.

It is a SW problem. Get the USB UART Click and capture the output. You might need to cut the power pin to avoid providing power via the Click. Also, don’t leave it on there long and potentially damage the processor by driving the UART line. Maybe even cut the RX (Click Board to PocketBeagle) signal as well (since you only need to monitor).

  1. I think there is no way to get the voltage rails to 0V due to the 3.3V bug. But, is it safe to always disconnect the battery in that state (PWR LED and USR2 LED are on after pressing the PWR button to shut the PocketBeagle down)?

Are you talking about the LDO? Doesn’t make any impact on PocketBeagle if you don’t use that 3.3V output. Not sure where the confusion is coming from.

Thanks Jason for your reply.

I installed the Stretch IoT Debian 9.4 from the beagleboard.org and I no longer have this issue. The problem occurred with the 9.3 version (not the 9.4 as I mentioned earlier in my post). I don’t remember having this issue when I first bought the PockeBeagle and installed Debian 9.3. But, when I had that issue, I wrote the post.

I wrote down the problem I captured on the serial log when it happened:

“rtc_power_off failed, bailing out.
Kernel panic”

Unfortunately, that’s all what I wrote down.

I am currently facing this issue, because I need to run the 9.3 kernel for compatibility reasons (some old PRU code). I know I can probably fix this issue by setting the RTC to internal clock, but I’m not sure how to do that in the best way. Is there a DTO available for it?

Erik

tirsdag den 28. august 2018 kl. 21.08.14 UTC+2 skrev An Ra:

Actually, i'm pretty sure this was u-boot problem?

Please post me your u-boot boot log right up to kernel load for
verification. If it is what i think it is, it's just one bit in the
rtc register.

But let's verify...

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.09/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L186-L193

Regards,

The log is attached. It includes startup as well as shutdown.

Thanks,

Erik

-----Oprindelig meddelelse-----

PBGL boot.txt (4.57 KB)