Challenges setting GPIO values [Solved:enabling Pi SPI overrides GPIO pins!]

[tpellegrini]

I am setting up a new ATXRaspi board for a PI 4 to mirror the configuration I had previously implemented for another PI which is operating without issue (running OctoPrint, FWIW).

The board is configured exactly as illustrated on the project page "Full poweroff from software" with the default GPIO pins. After reconfiguring the startup script and rebooting, I found the device was not responding to the button. (It does power up on successfully, and powers off "hard" after many seconds of holding.) I am seeing error when the the GPIO settings in the /etc/shutdowncheck.sh script which fails to run successfully as shown via this partial debug log of the output from running with sudo:

>>
+ SHUTDOWN=7
+ REBOOTPULSEMINIMUM=200
+ REBOOTPULSEMAXIMUM=600
+ echo 7
/etc/shutdowncheck.sh: line 11: echo: write error: Device or resource busy
+ echo in
/etc/shutdowncheck.sh: line 12: /sys/class/gpio/gpio7/direction: No such file or directory
+ BOOT=8
+ echo 8
/etc/shutdowncheck.sh: line 19: echo: write error: Device or resource busy
+ echo out
/etc/shutdowncheck.sh: line 20: /sys/class/gpio/gpio8/direction: No such file or directory
+ echo 1
/etc/shutdowncheck.sh: line 21: /sys/class/gpio/gpio8/value: No such file or directory
+ echo -e '\n=========================================================================================='
<<

The other PI does not have this same issue with the identical script. I checked first for a permissions difference for /sys/class/gpio/* but the folders appear to be identical to the other install:

>>
ls -al /sys/class/gpio/*
--w--w---- 1 root gpio 4096 Jan 29 16:57 /sys/class/gpio/export
lrwxrwxrwx 1 root gpio    0 Jan 29 16:48 /sys/class/gpio/gpiochip0 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 Jan 29 16:48 /sys/class/gpio/gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip504
--w--w---- 1 root gpio 4096 Jan 29 16:48 /sys/class/gpio/unexport
<<

The working install also has the expected output folders matching the GPIO assignments:

>>
lrwxrwxrwx 1 root root    0 Jan 24 19:47 /sys/class/gpio/gpio7 -> ../../devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio7
lrwxrwxrwx 1 root root    0 Jan 24 19:47 /sys/class/gpio/gpio8 -> ../../devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio8
<<

I did also try the python script variant which was recommended in the shutdownchecksetup.sh, but was unsuccessful in getting it working in this mode, either. I figured I'd fall back to the "more familiar" option.

I apologize in advance for my ignorance. I've spent a lot of time going around in circles so I'm waving the flag and probably holding myself out for embarrassment in hopes of getting some professional guidance.

Thanks in advance.


~ Tony



 

[Felix]

There's some kind of problem with the gpio module:

/sys/class/gpio/gpio8/direction: No such file or directory
/sys/class/gpio/gpio8/value: No such file or directory

Did that install correctly?

But why not just clone the image and transfer it to the new Pi?

[tpellegrini]

Sorry for the delay in getting back.

> But why not just clone the image and transfer it to the new Pi?

This was an existing OctoPrint instance that had everything except the ATXRaspi board, so adding that should have been trivial.

I used a boot disk from another device that had the board configured already. It behaves correctly, so clearly this isn't a hardware issue. I struggled with this for a few more hours but ended up rebuilding with an updated Octopi image (as suggested) and it is now working correctly. This resolves the issue but doesn't answer what was happening, which I'd love to understand. Not as much as getting back to having it working, tho.

I appreciate the guidance you offered

[Felix]

I did have issues with Octoprint (not atxraspi related) and kept wanting my old built image.
I gave up and reinstalled and all works so ... not sure it's worth further investigation.

[tpellegrini]

I'm going to necro my own thread here as I am back facing this challenge again after it was working without issue for a couple of months. That is, the software commands no longer work correctly to control the ATXRaspi board.

I have the python initialization method configured in rc.local like so:

python /etc/shutdownirq.py &

When it runs , the following is displayed:

>>
===========================================================================================
    ATXRaspi shutdown IRQ script started: asserted pins ( 7 =input,LOW; 8 =output, HIGH)
    Waiting for GPIO 7 to become HIGH (short HIGH pulse=REBOOT, long HIGH=SHUTDOWN)...
===========================================================================================
/etc/shutdownirq.py:18: RuntineWarning: This channel is already in use
, continuing anyway. Use GPIO.setwarnings(False) to disable warnings.
   GP10.setup(BOOT, GPI0.0UT, initial=GPI0 HIGH)
/etc/shutdownirq.py:21: RuntineWarning: This channel is already in use
. continuing anyway. Use GPIO.setwarnings(False) to disable warnings.
   GP10.setup(SHUTDOWN, GPI0.IN, pull_up_down=GPI0.PUD_DOWN)
<<

When I look at the devices, these two GPIO devices are not listed:

>>
pi@op1:~ $ ls -al /sys/class/gpio
total 0
drwxrwxr-x  2 root gpio    0 Apr  5 10:57 .
drwxr-xr-x 69 root root    0 Feb 14  2019 ..
--w--w----  1 root gpio 4096 Apr  5 10:57 export
lrwxrwxrwx  1 root gpio    0 Apr  5 10:57 gpiochip0 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip0
lrwxrwxrwx  1 root gpio    0 Apr  5 10:57 gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip504
--w--w----  1 root gpio 4096 Apr  5 10:57 unexport
<<

I expect to see two additional devices ("directories") representing GPIOs 7 and 8, which is how another system configured similarly shows this:

>>
pi@op2:~ $ ls -al /sys/class/gpio
total 0
drwxrwxr-x  2 root gpio    0 Apr  2 13:38 .
drwxr-xr-x 68 root root    0 Feb 14  2019 ..
--w--w----  1 root gpio 4096 Apr  2 13:38 export
lrwxrwxrwx  1 root root    0 Apr  2 13:38 gpio7 -> ../../devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio7
lrwxrwxrwx  1 root root    0 Apr  2 13:38 gpio8 -> ../../devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio8
lrwxrwxrwx  1 root gpio    0 Apr  2 13:37 gpiochip0 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip0
lrwxrwxrwx  1 root gpio    0 Apr  2 13:37 gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip504
--w--w----  1 root gpio 4096 Apr  2 13:37 unexport
<<

Note that this other install uses the other initialization method, /etc/shutdowncheck.sh. However, if I try using this variant I get the same error that started this thread a couple months ago:

>>
pi@op1:~ $ sudo /etc/shutdowncheck.sh
/etc/shutdowncheck.sh: line 11: echo: write error: Device or resource busy
/etc/shutdowncheck.sh: line 12: /sys/class/gpio/gpio7/direction: No such file or directory
/etc/shutdowncheck.sh: line 19: echo: write error: Device or resource busy
/etc/shutdowncheck.sh: line 20: /sys/class/gpio/gpio8/direction: No such file or directory
/etc/shutdowncheck.sh: line 21: /sys/class/gpio/gpio8/value: No such file or directory

==========================================================================================
   ATXRaspi shutdown POLLING script started: asserted pins (7=input,LOW; 8=output,HIGH)
   Waiting for GPIO7 to become HIGH (short HIGH pulse=REBOOT, long HIGH=SHUTDOWN)...
==========================================================================================
cat: /sys/class/gpio/gpio7/value: No such file or directory
/etc/shutdowncheck.sh: line 32: [: =: unary operator expected
/etc/shutdowncheck.sh: line 36: [: =: unary operator expected
cat: /sys/class/gpio/gpio7/value: No such file or directory
/etc/shutdowncheck.sh: line 32: [: =: unary operator expected
/etc/shutdowncheck.sh: line 36: [: =: unary operator expected
cat: /sys/class/gpio/gpio7/value: No such file or directory
/etc/shutdowncheck.sh: line 32: [: =: unary operator expected
/etc/shutdowncheck.sh: line 36: [: =: unary operator expected
...
<<

Naturally this is because the expected folders are not present.

So this was working for a couple months then failed when I was trying to resolve an issue with a temp sensor (DHT11) not reporting correctly. I had [re-]installed several items. Perhaps one is conflicting somehow?

>>
sudo pip3 install --upgrade setuptools
sudo pip3 install --upgrade adafruit-python-shell
pip3 install adafruit-circuitpython-dht
sudo apt-get install libgpiod2
pip3 install sysv-ipc
<<

I have tested writing the outputs manually, but keep getting the permissions issue when I use the shell or the "This channel is already in use" from pytrhon. If I use a different pin number (e.g. 6) the system behaves as expected, creating the folder structure, etc. So what could have happened that the system can no longer function correctly for these pins? Most importantly, how do I fix it?

The last time I started over with a fresh image. Undesirable as it was, I did it before. I'm very disinclined to do that again. I need to understanding what's happening and how to fix it.

TIA.


~ Tony

[tpellegrini]

OK, I finally figured out my issue.

At some point and for some reason, I had enabled SPI. I have now learned after reading hundreds of pages/blog posts that SPI conflicts with the "base" GPIO functionality. When enabled, SPI "takes ownership" of the GPIO pins assigned, which includes the pins used in the example for the ATXRaspi poweroff from software page. GPIO7, GPIO8, and GPIO10 have specific SPI functionality, so when I unwittingly enabled SPI, I effectively "repurposed" those pins to SPI and OUT OF GPIO control. The simple fix, therefore, was to disable SPI via raspi-config, after which full functionality was restored. I'm sure I could also have selected different GPIO pins that were not conflicting with the SPI assignments, but that would have involved disassembly of the components which I knew was not necessary since the system had been working previously.

Not for anything, but an asterix/footnote on the web page detailing the ATXRaspi configuration for software control would be helpful for others like me who are not so well versed in these sorts of things.

Hopes this helps others in need.