So we have been using GPIO 50 on the BBB with older releases such as Debian 8.3 for a while now with no issues.
We have updated to stretch Debian 9.4 in the past few days.
I am setting the gpio export as follows: (in script on boot)
sudo su
echo 50 > /sys/class/gpio/export
Then I echo to these files to use the GPIO and it works as expected.
/sys/class/gpio/gpio50/value
/sys/class/gpio/gpio50/direction
What I have noticed though is that on at least one of the boards the entire “/sys/class/gpio/gpio50/” folder will randomly go missing, then reappear a few seconds or minutes later.
This either started after a few reboots or it was like this the whole time on 9.4 but it took a while to notice the issue.
For example I can be in /sys/class/gpio/ then call the ls command. If I repeat this command over and over again sometimes the gpio50 will show up, and sometimes it won’t. Most of the time it won’t show up.
Sometimes I can navigate into the gpio50 folder, but then the various files and sub folders will be missing.
When this folder disappears the application we are using fails to control the GPIO using fwrite, so it isn’t just cosmetic.
Does this mean the pin is fried and this is a hardware feature to disable a fried pin, or could the system be doing something else in the background where it tries to claim this pin for something else?
I have tried searching and I couldn’t find any other case of the disappearing device tree folder like this.
We had originally chosen this pin for PWM but never implemented it, so I am open to suggestions if there is a better GPIO I should be using for basic 3.3 level switching. (one that is guaranteed to work without having to disable a bunch of features in the system)
Thanks in advance for any help.
Bill
I have finally been able to get back to working on this again.
I have now seen the problem on 2 different BBBs (but not a third one yet) so maybe this isn’t a hardware problem?
Here is an example of what I see. The GPIO will randomly appear and disappear on certain BBBs.
You can use the watch -n1 ls command to see it automatically update. This can happen even with nothing physically connected to the pin.
Has anybody else seen this problem before on any GPIO?
`
debian@beaglebone:~$ cd /sys/class/gpio/
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip0 gpiochip64 unexport
gpio12 gpio50 gpiochip32 gpiochip96
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip0 gpiochip64 unexport
gpio12 gpio50 gpiochip32 gpiochip96
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip0 gpiochip64 unexport
gpio12 gpio50 gpiochip32 gpiochip96
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip32 gpiochip96
gpio12 gpiochip0 gpiochip64 unexport
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip32 gpiochip96
gpio12 gpiochip0 gpiochip64 unexport
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip32 gpiochip96
gpio12 gpiochip0 gpiochip64 unexport
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip32 gpiochip96
gpio12 gpiochip0 gpiochip64 unexport
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip32 gpiochip96
gpio12 gpiochip0 gpiochip64 unexport
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip32 gpiochip96
gpio12 gpiochip0 gpiochip64 unexport
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip32 gpiochip96
gpio12 gpiochip0 gpiochip64 unexport
debian@beaglebone:/sys/class/gpio$ ls
export gpio13 gpiochip0 gpiochip64 unexport
gpio12 gpio50 gpiochip32 gpiochip96
`
Bill
I finally figured this out.
The service I had created was constantly calling the export on the pin, which I assume would cause the list to “refresh” or something like that.
Stopping the service while the pin was “there” would cause the pin to stay. But if I stop the service when the pin is missing it stays missing.
I still need to confirm in the application that the pin works correctly every time but this probably settles this issue.
Later I can post up my scripts/service for reference once I get a final version.
Bill