MacArthur hat with power module powerdown issue?

[EricGesner]

Interestingly this is different than in my post at Yesterday, 03:12 PM !?!? 
GPIO26 level 1 has change
Also I monitored GPIO26 during power on with the switch.  It went from 0V to about 3.3V briefly and then quickliy settled down to 0.4V
What could be causing that?

A few minutes ago:
pi@openplotter:/ $ raspi-gpio get 21
GPIO 21: level=1 fsel=0 func=INPUT pull=UP
pi@openplotter:/ $ raspi-gpio get 26
GPIO 26: level=0 fsel=1 func=OUTPUT pull=DOWN

Yesterday, 03:12 PM
pi@openplotter:~ $ raspi-gpio get 21
GPIO 21: level=1 fsel=0 func=INPUT pull=UP
pi@openplotter:~ $ raspi-gpio get 26
GPIO 26: level=1 fsel=1 func=OUTPUT pull=DOWN

pi@openplotter:/boot $ raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT pull=UP
GPIO 1: level=1 fsel=0 func=INPUT pull=UP
GPIO 2: level=1 fsel=4 alt=0 func=SDA1 pull=UP
GPIO 3: level=1 fsel=4 alt=0 func=SCL1 pull=UP
GPIO 4: level=1 fsel=0 func=INPUT pull=UP
GPIO 5: level=1 fsel=0 func=INPUT pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=1 fsel=0 func=INPUT pull=UP
GPIO 8: level=1 fsel=0 func=INPUT pull=UP
GPIO 9: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 10: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 11: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 12: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 13: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 14: level=1 fsel=0 func=INPUT pull=NONE
GPIO 15: level=1 fsel=0 func=INPUT pull=UP
GPIO 16: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 17: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 18: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 19: level=1 fsel=0 func=INPUT pull=NONE
GPIO 20: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 21: level=1 fsel=0 func=INPUT pull=UP
GPIO 22: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 23: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 24: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 25: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 26: level=0 fsel=1 func=OUTPUT pull=DOWN
GPIO 27: level=0 fsel=0 func=INPUT pull=DOWN
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=2 alt=5 func=RGMII_MDIO pull=UP
GPIO 29: level=0 fsel=2 alt=5 func=RGMII_MDC pull=DOWN
GPIO 30: level=0 fsel=7 alt=3 func=CTS0 pull=UP
GPIO 31: level=0 fsel=7 alt=3 func=RTS0 pull=NONE
GPIO 32: level=1 fsel=7 alt=3 func=TXD0 pull=NONE
GPIO 33: level=1 fsel=7 alt=3 func=RXD0 pull=UP
GPIO 34: level=1 fsel=7 alt=3 func=SD1_CLK pull=NONE
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD pull=UP
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0 pull=UP
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1 pull=UP
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2 pull=UP
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3 pull=UP
GPIO 40: level=1 fsel=4 alt=0 func=PWM1_0 pull=NONE
GPIO 41: level=0 fsel=4 alt=0 func=PWM1_1 pull=NONE
GPIO 42: level=0 fsel=1 func=OUTPUT pull=UP
GPIO 43: level=1 fsel=0 func=INPUT pull=UP
GPIO 44: level=1 fsel=0 func=INPUT pull=UP
GPIO 45: level=1 fsel=0 func=INPUT pull=UP
BANK2 (GPIO 46 to 53):
GPIO 46: level=0 fsel=0 func=INPUT pull=UP
GPIO 47: level=0 fsel=0 func=INPUT pull=UP
GPIO 48: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 49: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 50: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 51: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 52: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 53: level=0 fsel=0 func=INPUT pull=DOWN

[Sailoog]

It seems that your system is not digesting the last line in your config.txt file:

dtoverlay=gpio-poweroff,gpiopin=26,active_low=1

We could try to set the GPIO using some commands to check if the GPIO value changes.

- Measure the voltage in GPIO 26
- Check the state is consistent with the measured value using "raspi-gpio get 26"
- Set the GPIO to high using "raspi-gpio set 26 op dh"
- Measure the voltage consistency again.

[EricGesner]

During power up GPIO26 went to 3.29V for a few secconds and then went to 0V

Here are results from the experiment you suggest
It is taying at 3.29V after setting it with raspi-gpio

pi@openplotter:~ $ raspi-gpio get 26
GPIO 26: level=0 fsel=1 func=OUTPUT pull=DOWN
pi@openplotter:~ $ raspi-gpio set 26 op dh
pi@openplotter:~ $ raspi-gpio get 26
GPIO 26: level=1 fsel=1 func=OUTPUT pull=DOWN

Also I monitored GPIO26 over several power ups yesterday.
In about 8 power ups, roughly half the time GPIO 26 went to 0 volts 0.4V sometime 0 and sometimes 0.4V,
and about half the time GPIO26 went to and stayed at 3.29 volts after powerup
It was seemingly random.

Also, the shutdown & boot history from the "last -x" commandreveals a difference betwnn when GPIO stays at 3.29V and when it drops to less than 1V.  Below in the "last -x results the tty1 & tty7  lines at 9:15 with "gone - no logout" corresponds to a reboot where GPIO26 drops below 1V  and the tty1 & tty7 lines at 19:20 correspond to a reboot where GPIO26 stays at 3.29V 

pi@openplotter:~ $ last -x
runlevel (to lvl 5)  6.1.21-v8+      Wed Feb 21 19:25  still running
pi      tty7        :0              Wed Feb 21 19:25    gone - no logout
pi      tty1                          Wed Feb 21 19:25    gone - no logout
reboot  system boot  6.1.21-v8+      Wed Dec 31 19:00  still running
shutdown system down  6.1.21-v8+      Wed Feb 21 19:25 - 19:00 (-19775+00:25)
runlevel (to lvl 5)  6.1.21-v8+      Wed Feb 21 19:20 - 19:25  (00:04)
pi      tty7        :0              Wed Feb 21 19:20 - 19:25  (00:04)
pi      tty1                          Wed Feb 21 19:20 - down  (00:04)
reboot  system boot  6.1.21-v8+      Wed Dec 31 19:00 - 19:25 (19775+00:25)
shutdown system down  6.1.21-v8+      Wed Feb 21 19:20 - 19:00 (-19775+00:20)

[Sailoog]

OK, then the settings are being applied but there is something in your system that is lowering the GPIO 26.

Do you have any sensor, device, HAT connected that could be trying to use the GPIO26?

Do you have any setting or program that could be trying to access to the GPIO 26? openplotter-gpio app, openplotter-notifications app, node-red, any python script...?

Performing a fresh installation of OpenPlotter v3 may help rule out configuration issues.

[EricGesner]

Thanks, I don't think I have anything else using GPIO26.
Only have MacArthur hat, ds18b20 onewire, IMU on i2c and GPS on USB.
Tomorrow, I intend to try a clean install of openplotter 3 on a new SD card.
I did reproduce the problem with the 12V and power module removed from the MacArthur hat.

[EricGesner]

I have tested three times with a fresh installation of Openplotter 3 on a new SD card.
The problem reproduces after I enable the remote GPIO and install GPIO in the settings dialog.
In all three attempts prior to installing GPIO in the settings dialog, the poweroff and shutdown was working reliably and GPIO26 was high after many reboots.
Additionally, subsequently uninstalling GPIO in the Settings dialog appears to result in GPIO26 set to level=1 after multiple shutdowns and reboots.
There seems to be a correlation between installing GPIO in the settings dialog and the issue with GPIO26 not consistently achieving 3.3V after reboot.
I have also noticed that GPIO26 occasionally switches between level=1 and level=0 after a reboot.

[Sailoog]

I will take a look at this ASAP, thanks.

[EricGesner]

Thank you for investigating!
I did reproduce the issue in both 32bit and 64bit openmarine.
I did reproduce both with and without MacArthur hat installed.

The following mention of using a custom dt-blob.bin may be relevant based on my research, however I'm not an expert pertaining to Raspberry pi or GPIO use:
This is an excerpt pertaining to gpio-poweroff from https://github.com/raspberrypi/firmware/...ays/README:

active_low 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.

[EricGesner]

New information.
I have not seen the problem with GPIO26 low after boot since I turn off the Raspberry Pi Config System setting for Splash Screen. This has been for several days and 40 or more reboots.
I have tested turning the Spash Screen back on and reproduced the problem.
The problem always has been intermittant which makes me suspect it is affected by timing during boot or possibly memory corruption. I'm thinking that turning off the Splash Screen and the corresponding messages displayed in the console may impact the timing. For now this appears to be a workaround...