Lgpio.error: 'GPIO busy' from test scripts

[PiRSquared]

I run the test scripts e.g. tail.py and it runs OK.

pip@pidog:~/pidog/test $ sudo python3 tail.py
config_file: /home/pip/.config/pidog/pidog.conf
robot_hat init … done
imu_sh3001 init … done
rgb_strip init … done
dual_touch init … done
sound_direction init … done
sound_effect init … pinctrl set 12 op dh
done
ultrasonic init … done
Stopping and returning to the initial position …
Quit
pip@pidog:~/pidog/test $

However, the script does not terminate fully and if I do a ‘ps -ef’ the task is still present in memory.

pip@pidog:~/pidog/test $ ps -ef | grep tail
root 4477 1 28 11:05 ? 00:00:31 python3 tail.py
pip@pidog:~/pidog/test $

If I try to run this or any other script they fail with the GPIO busy error. I can kill the task manually and then tasks will run again. However I assume this is not the correct behaviour.

The scripts make a call to my_dog(close) at the end could this be failing in some way?

The script terminates cleanly and returns to the prompt. However, if I abort the task before it completes then the process is removed from memory!!

Thank you in advance.

(P.S. This is running remotely from ssh or a shell prompt on the RPI. RPI V4.

[Spf650]

That’s the normal behaviour, albeit probably unexpected!

You’re running into a hard boundary between OS-managed resources and external hardware state. A ctrl-c, such as early program termination or interrupting an Infinite loop frees the mcu resources from the linux core, whereas other exit methods do not.

As far as I could ever determine, dog.close() is not a cleanup method, it is a terminal control-flow primitive, it assumes it is called from top-level code and it was never meant to return.

So, in summary, what you see is normal. The other examples that run infinitely, will need ctrl-c to terminate anyway and this then automatically frees resources. They are absolutely fine.

I tried to explain the options a bit better here via 3 different worked example scenarios

GPIO state after a program abort or user exit

I hope this little topic is of some help I’ve seen several user questions whereby when a program terminates incorrectly for whatever reason, it can leave the GPIO in a “busy” state. Usually requiring a reboot. Instead of a reboot one can often find the owner process id and just kill it e.g running some python code such as DummySpeech.py may show … File “/usr/lib/python3/dist-packages/lgpio.py”, line 458, in _u2i raise error(error_text(v)) lgpio.error: ‘GPIO busy’ on subsequent runs. To …

Please note the above is my own interpretation and probably over simplified version of the process via a bit of reverse engineering, not confirmed in any way by Sunfounder, please feel free to ignore! I could be totally wrong.

[PiRSquared]

Thank you for your reply. To explain, I have only just finished construction so currentlly don’t know what is normal and what isn’t.

What you say is certainly the same as I am experiencing.

At least two of the test scripts do not exhibit this behaviour - rgb_strip_test.py and imu_test.py These do not leave a process running and in fact run even if another task has been left running. I had assumed that these also involved the GPIO but they daisy chain off the I2C which must be independent of GPIO.

I had also assumed that even though this kit is probably not aimed at a complete beginner that the instructions would cover how to deal with the GPIO error when running scripts in the instructions. I have experience of electronics and Linux, so was able as you were to work out what to do but many people may not. Early days yet but I’m guessing it isn’t in the Sunfounder instructions and I have to admit to not fully watching/reading every bit of the insructions.