You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Image lifted from one of the reference links below].
The Pi has manifested this issue for some time, but as I'm the only one likely to ever encounter it, I've had it low on the TODO list.
Previuous investigations have revealed the cause: that by using gpio-poweroff in the setup.sh script (as part of the handshaking between Pi and Arduino) I've broken the normal shutdown process.
#Set GPIO27 to follow the running state: it's High while running and 0 when shutdown is complete. The Arduino will monitor this pin.
dtoverlay=gpio-poweroff,gpiopin=27,active_low
"Use of this overlay (and the gpio-poweroff mechanism) required that there is an external mechanism to remove the power in response to the GPIO being toggled. Failure to do so within the allowed window (3 seconds is the default) results in a kernel warning, followed by undefined behaviour."
Today I've encountered the same kernel panic in another Pi-based project, and I commenced some fresh investigation into the issue, which has unearthed this apparent gem:
"Some approaches for a constant status led (ab)use the gpio-poweroff overlay which interrupts proper shutdown procedures, but gpio-led doesn’t."
So I'm experimenting with this as a replacement line: dtoverlay=gpio-led,gpio=27,trigger=default-on,active_low
It won't be in 'vNext' (4.5.1) as I want to let it soak for QUITE a while in Dev before I let it loose on you.
Hi Greig,
I am experiencing the same bug with intvlmt8r 4.5.2 (I am trying right now the new version 4.5.3).
I will try to update the setup.sh script uncommenting these lines of code and I will test it.
Please be VERY careful tinkering with any of the code that controls the power interaction between the Pi and the Arduino. Get that wrong and you risk bricking the intvlm8r - hence why i've been taking it very carefully.
This 'issue' isn't one anyone will encounter in the field - it only manifests on the bench, so I wouldn't be too concerned for it.
Having said that I'm happy to receive input and suggestions if you do invest some time into it.
[Image lifted from one of the reference links below].
The Pi has manifested this issue for some time, but as I'm the only one likely to ever encounter it, I've had it low on the TODO list.
Previuous investigations have revealed the cause: that by using
gpio-poweroff
in the setup.sh script (as part of the handshaking between Pi and Arduino) I've broken the normal shutdown process.#Set GPIO27 to follow the running state: it's High while running and 0 when shutdown is complete. The Arduino will monitor this pin. dtoverlay=gpio-poweroff,gpiopin=27,active_low
References:
https://forums.raspberrypi.com/viewtopic.php?t=143519
https://raspberrypi.stackexchange.com/questions/127947/pi-zero-doesnt-fully-shut-down-after-adding-a-gpio-poweroff-dtoverlay-to-boot
Yup, this is me:
Today I've encountered the same kernel panic in another Pi-based project, and I commenced some fresh investigation into the issue, which has unearthed this apparent gem:
So I'm experimenting with this as a replacement line:
dtoverlay=gpio-led,gpio=27,trigger=default-on,active_low
It won't be in 'vNext' (4.5.1) as I want to let it soak for QUITE a while in Dev before I let it loose on you.
More references:
https://raw.githubusercontent.com/raspberrypi/firmware/master/boot/overlays/README
- Greig.
The text was updated successfully, but these errors were encountered: