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 On Monday, August 6, 2018 at 10:16:53 AM UTC-5, Bill Fleming wrote: > > 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 > > > On Wednesday, July 18, 2018 at 6:46:23 PM UTC-5, Bill Fleming wrote: >> >> 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 >> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/71019c12-0a1b-48c5-99ec-255743710478%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
