Incompatible with RedBear IoT pHAT?

drewcovi commented 7 years ago

Based on the requirements for bluetooth it would appear this setup wouldn't work with the RedBear IoT pHAT... are there any changes that would accommodate this device?

https://github.com/redbear/IoT_pHAT

NeonHorizon commented 7 years ago

GPIO 14 (UART TXD) is the only pin which goes high at power on and low at power off, if it uses that you wont have much luck. However if you check the issues, others have used different pins but they had to write a script to make the GPIO high and hold the power button down until the Pi is booted.

tommcintyre commented 7 years ago

I had the same issue (wanting to use LiPoPi with the IoT pHAT (which blocks out a LOT of GPIO pins) - and also wanting my serial console back!), and ended up with the following workaround. This seems to be working OK for me, but I'm not sure how sensible/portable/reliable this is - someone with a better understanding of the electronics side might be able to comment?

Instead of GPIO 14, use GPIO 0 (ID_SD / pin 27). On my Pi Zero at least, this seems to go high early in the boot process (hold button for ~3 seconds), and then stay that way indefinitely. It doesn't need to be manually set high with a script, etc.
However, it does need to be manually set low at the end of system shutdown in order to turn off the PowerBoost. I'm using the attached script and systemd service file to do this. This runs as close to shutdown as seems to be possible with systemd.
For some reason I haven't worked out yet, the shutdown script only seems to trigger on reboot, and not system halt. Therefore, instances of shutdown -h in lipopi.py need to be changed to shutdown -r. (This isn't an ideal solution and needs fixing properly if the rest of this approach is acceptable).

signal_poweroff.zip

NeonHorizon commented 7 years ago

Surely running a script to change the GPIO is a bad idea as it will cut the power whilst the OS is still running?

tommcintyre commented 7 years ago

I'm fairly happy cutting the power at that late stage because it's after filesystems get remounted readonly, etc., basically right before poweroff would happen normally (see log below) - but yeah, it's possible doing it even later e.g. outside of systemd would be even cleaner.

I was wondering about adding a capacitor across the GPIO pin to give it extra time to complete full software shutdown at the hardware level. The other option might be to get into the kernel/initd/ACPI. Or I could just be barking up the wrong tree here... :)

For info here's my serial/dmesg log for the shutdown process as it stands now:

[  OK  ] Started Show Plymouth Reboot Screen.
[  OK  ] Stopped target Network.
         Stopping dhcpcd on all interfaces...
[  OK  ] Stopped target Remote File Systems.
[  OK  ] Stopped target Remote File Systems (Pre).
[  OK  ] Stopped dhcpcd on all interfaces.
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped target Slices.
[  OK  ] Removed slice User and Session Slice.
[  OK  ] Stopped target Paths.
[  OK  ] Stopped target Timers.
[  OK  ] Stopped target Sockets.
[  OK  ] Closed Syslog Socket.
[  OK  ] Closed Avahi mDNS/DNS-SD Stack Activation Socket.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Stopped target System Initialization.
         Stopping Restore / save the current clock...
         Stopping Update UTMP about System Boot/Shutdown...
[  OK  ] Stopped target Encrypted Volumes.
         Stopping LSB: Raise network interfaces....
[  OK  ] Stopped target Swap.
[  OK  ] Stopped Update UTMP about System Boot/Shutdown.
[  OK  ] Stopped Restore / save the current clock.
         Stopping Create Volatile Files and Directories...
[  OK  ] Stopped Create Volatile Files and Directories.
[  OK  ] Stopped LSB: Raise network interfaces..
         Stopping Apply Kernel Variables...
[  OK  ] Stopped Apply Kernel Variables.
         Stopping Load Kernel Modules...
[  OK  ] Stopped Load Kernel Modules.
         Stopping Load/Save Random Seed...
[  OK  ] Stopped target Local File Systems.
         Unmounting /boot...
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Unmounted /boot.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped target Local File Systems (Pre).
         Stopping Create Static Device Nodes in /dev...
[  OK  ] Stopped Create Static Device Nodes in /dev.
         Stopping Remount Root and Kernel File Systems...
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target Shutdown.
[   55.130015] reboot: Restarting system
*** GPIO pin pulled low here and system powers off

NeonHorizon commented 7 years ago

Yeah I see what you are saying. The only problem I see is technically the SD card will still be powered up so you could corrupt the SD card from the falling power edge.

Not sure what the odds of that happening are though. I know it was a bigger issue on the early PI's.

tommcintyre commented 7 years ago

Good point, either way it feels messy. I guess the correct place to do it would be wherever final poweroff normally happens, which is probably in the kernel or ACPI. I might see if I can do some more digging.

NeonHorizon commented 7 years ago

I'd be really impressed if you managed that :) In the meantime a large cap might be the answer?

tommcintyre commented 7 years ago

(No need to reopen, but the notification reminded me to reply.)

I was getting some weird behaviour adding the large cap - it did do the job (even allowed "reboot" to work!) but it also seemed to introduce some other inconsistencies which I haven't had a chance to look into further yet. I'll post again if I make any progress, as having access to serial lines is still a big requirement for me.

Although @drewcovi, an easier solution to your original issue might be to ditch the pHAT and get a Pi Zero W? :)

NeonHorizon / lipopi

Incompatible with RedBear IoT pHAT? #18