-1

I'm working on a soft-latching power control for my raspberry PI project. I want to use the 'gpio-poweroff' overlay to cut all power after the system gracefully shuts down. I have it working, but I'm seeing some odd behavior.

To test I started with a fresh install (32 bit Bullseye Lite 2-21-2023) and added this line to the end of config.txt:

dtoverlay=gpio-poweroff,gpiopin=10,active_delay_ms=5000,inactive_delay_ms=4000

Then I monitored pin 10 with a multimeter:

pin is low on powerup
I log in (over Wifi via ssh from my Mac), and I shutdown: $ sudo shutdown -h now
pin goes high for 5 seconds
pin goes low for 4 seconds
pin goes high and stays high.

This is exactly as described in the README. However, I need the pin to go high on system startup, and remain high until this poweroff sequence happens.

So, first I tried simply adding this 'gpio' line to turn the pin ON:

gpio=10=op,dh

The pin goes high within a second of startup, but about 5 seconds later goes low again. I suspect that the gpio setting happens; then the gpio-poweroff overlay overrides it. The behavior after issuing the shutdown command remains as before.

Next I removed the 'gpio' line and added the 'active_low' parameter to the dtoverlay line:

dtoverlay=gpio-poweroff,gpiopin=10,active_low=1,active_delay_ms=5000,inactive_delay_ms=4000

I now get this:

pin is low at powerup
brief delay (5 seconds or so)
pin goes high
I log in and shut down
Pin goes low and stays low

This will also work for me, but I'm wondering why I didn't get the original behavior, just with inverted pin values. I expected:

powerup
brief delay
pin goes high
I shut down
pin goes low 5 seconds
pin goes high 4 seconds
pin goes low and stays low

...I'm not seeing the expected Low-High-Low pattern.

The README has this to say about the active_low parameter:

Set if the power control device requires a
high->low transition to trigger a power-down.
Note that this will require the support of a
custom dt-blob.bin to prevent a power-down
during the boot process, and that a reboot
will also cause the pin to go low.

In my case, rebooting shouldn't be an issue, and I solved the 'power-down during boot' problem by restoring that 'gpio' line to raise the pin earlier. My power control circuit explicitly waits for a 'long' low signal (to ignore any noise) ...hence the 5 second delay.

So, finally my questions:

  • Am I OK as-is? Or, is there some good reason I should monkey around with a custom dt-blob.bin? If so, can you point me to an example?

  • Why isn't the behavior with active_low an exact mirror of the behavior without it?

These just out of curiosity:

  • What's the point of the 'input' parameter? How could you possibly signal your power-control system if the pin was configured as input?

  • The 'timeout_ms' parameter lets me configure a delay before the kernel issues a 'WARN'. I understand I'm expected to cut power before that happens, but what if I don't? What are the implications of the kernel issuing this 'WARN' after the OS is already shut down?

  • Where can I find the source for the power-off module? (I don't mean the .dts file; I mean the actual implementation).

TIA!

1
  • Yes I did. Did you actually read my post? I'm pointing out that the default behavior creates a conventional pulse, but it does not create such a pulse when the 'active low' parameter is used. It works for me, but I'm wondering why the behavior isn't strictly mirrored.
    – mkeveney
    Apr 14, 2023 at 22:35

2 Answers 2

0

I think you're asking for trouble if you use the optional parameters. I've used the gpio-poweroff overlay on 2 or 3 projects, and it's always worked perfectly with the default settings; i.e.:

In /boot/config.txt:

dtoverlay=gpio-poweroff

I don't understand what you mean by "a soft-latching power control". AFAIK, gpio-poweroff does one thing: It interrupts the kernel's shutdown process to issue a signal to an external control device (e.g. relay) to remove power. From the documentation:

Users of this overlay are required to provide an external mechanism to switch off the power supply when signalled - failure to do so results in a kernel BUG, increased power consumption and undefined behaviour.

In case you're wondering what the gpio-poweroff signal looks like, I've added a screenshot from my oscilloscope below. Note that in this picture, the gpio-poweroff signal is not actually being used to disconnect power; if it were, you would see the 3V3 voltage on GPIO 26 begin to decay toward zero.

gpio-poweroff

Here is an example of an external mechanism to switch off the power supply when signaled - GPIO 26 drives a small NPN transistor which in turn actuates a latching relay coil on K1 to open the contacts that deliver power to the RPi. In other words, in this implementation of an external mechanism power is removed from the RPi when GPIO 26 goes HIGH, and power is not restored until the START momentary pushbutton is pressed. Hope that clears things up; please let us know if not.

"external mechanism" for power removal

4
  • Please explain why you think I'm "asking for trouble if I use the optional parameters."
    – mkeveney
    Apr 14, 2023 at 22:29
  • The "Latching power control" I mention is my implementation of the "external mechanism to switch off the power" you cite from the documentation. My circuit uses FETs, but accomplishes the same thing as yours. It's working fine, so I did not post the details.
    – mkeveney
    Apr 14, 2023 at 22:32
  • @mkeveney: Re "asking for trouble": I've found that to be true on a few other overlays/parameters. I don't know whether it's due to firmware diffs between the various models, or poor documentation (e.g. the use as input parameter), but it's happened several times.
    – Seamus
    Apr 15, 2023 at 0:21
  • @mkeveney: Re: "latching power control". That's great; I only mentioned it in an effort to make it clear that additional hardware is required.
    – Seamus
    Apr 15, 2023 at 0:23
0

dtoverlay -h gpio-poweroff will display the documentation.

In my experience active-low creates problems. It is far easier to design your circuitry to use the default.

1
  • Please describe the problems you've experienced.
    – mkeveney
    Apr 14, 2023 at 22:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.