So as the subject says we’re having issues with gpio1_16 and gpio2_0 being tied together through r161. We’ve removed r161 on one beaglebone green, then export gpio48(gpio1_16) through sysfs, set the direction to ‘in’, in an attempt to read input to an externally connected sensor. This does not work. However, as soon as we swap the BBG out for a BBB, the software we have reading the input pins works perfectly.
So my question is this: Is there some sort of software binding through the initial boot board device tree file between these two pins that also needs to be changed ? Instead of or including removing r161 ?
Additionally, using:
$ sudo config-pin overlay univ-all
$ sudo config-pin P9.15 hi / low
Seems to work fine on the BBG too. However the idea is to use P9.15 as normal through sysfs. Without having to mux the pins. If at all possible. But since pin is not exactly brought out to the header( except that it’s tied to gpio1_16 ) it’s not going to have a header pin value. However knowing the gpio number needing to be echoed into the export file would be fine too. It such a critter existed. Which I am thinking it is also possible that it also does
not exist . . .
err, that wrong what I said above. First, we have a circuit between another gpio, and gpio2_16 as a test circuit
. To test the input pin. So the overlay file univ-all is muxing the pins exactly right for us on this one input pin. However, as stated the board being used is intended to be used without universal io, config pin, or any of that.
No bites on this post ? I did find a post from 2014 where someone else was discussing with Gerald about this situation as well. But it appears now days the software is somehow overriding this behavior. Unless the designers of the green somehow messes up. I’ve not yet found anything in the board file.
/*
So, I think maybe I might have narrowed down the problem. My assumption is that gpio64(gpio2_0) is perhaps set
default by the processor to an output. Until the pin is exported via the sysfs gpio mechanism. One only need to export the pin and then everything works fine. I’ll confirm this later with an oscilloscope reading later to backup my assumption. With that said I dug through all the include files, headers, and whatnot. Conspicuously there was mention of emmc_pins for the green overlay file, but gpio2_0 was not muxed in the file am335x-bone-common.dtsi.
Worklog below, and yes this did physically toggle an LED on our test fixture.
debian@beaglebone:~$ ls /sys/class/gpio
export gpio115 gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport
debian@beaglebone:~$ sudo sh -c “echo ‘64’ > /sys/class/gpio/export”
debian@beaglebone:~$ ls /sys/class/gpio
export gpio115 gpio64 gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport
debian@beaglebone:~$ cat /sys/class/gpio/gpio64/direction
in
debian@beaglebone:~$ cat /sys/devices/platform/
alarmtimer/ fixedregulator@0/ omap-pcm-audio/ pmu/ serial8250/ ti-cpufreq.0/
bone_capemgr/ leds/ opp_table0/ power/ snd-soc-dummy/ uevent
cpufreq-dt/ ocp/ pm33xx.0/ reg-dummy/ soc/
debian@beaglebone:~$ cat /sys/devices/platform/
alarmtimer/ fixedregulator@0/ omap-pcm-audio/ pmu/ serial8250/ ti-cpufreq.0/
bone_capemgr/ leds/ opp_table0/ power/ snd-soc-dummy/ uevent
cpufreq-dt/ ocp/ pm33xx.0/ reg-dummy/ soc/
debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
debian@beaglebone:~$ sudo sh -c “echo ‘48’ > /sys/class/gpio/export”
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/direction
in
debian@beaglebone:~$ sudo sh -c “echo ‘51’ > /sys/class/gpio/export”
debian@beaglebone:~$ cat /sys/class/gpio/gpio51/direction
in
debian@beaglebone:~$ sudo sh -c “echo ‘out’ > /sys/class/gpio/gpio51/direction”
debian@beaglebone:~$ cat /sys/class/gpio/gpio51/direction
out
debian@beaglebone:~$ sudo sh -c “echo ‘1’ > /sys/class/gpio/gpio51/value”
debian@beaglebone:~$ sudo sh -c “echo ‘0’ > /sys/class/gpio/gpio51/value”
Ah, but the “Drama” continues . . .
debian@beaglebone:~$ sudo sh -c “echo ‘0’ > /sys/class/gpio/gpio51/value”
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
0
debian@beaglebone:~$ sudo sh -c “echo ‘1’ > /sys/class/gpio/gpio51/value”
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
0
Ok, that’s wrong . . . so. . .
debian@beaglebone:~$ wget https://raw.githubusercontent.com/cdsteinkuehler/beaglebone-universal-io/master/config-pin
debian@beaglebone:~$ chmod +x config-pin
debian@beaglebone:~$ sudo ./config-pin overlay univ-all
Loading univ-all overlay
debian@beaglebone:~$ sudo ./config-pin P9.16 hi
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
0
debian@beaglebone:~$ sudo ./config-pin P9.16 low
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
1
So, Robert, Charles, anyone ? What gives ?
Just for clarity
debian@beaglebone:~$ sudo sh -c “echo ‘1’ > /sys/class/gpio/gpio51/value”
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
0
debian@beaglebone:~$ sudo sh -c “echo ‘0’ > /sys/class/gpio/gpio51/value”
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
1
So, I’m not experiencing an “off by 1” issue. But for some reason gpio1_16 only works if a universal IO overlay that deals with gpio1_16 appropriately - somehow. I’m not sure what I’m missing. Is this a software bug of some sort ?
So, booting and loading am335x-bonegreen-overlay.dtb on a beaglebone green will render the board unbootable.
Let me rephrase that. The board seems to boot and come up, but I was unable to ssh into the board. For whatever reason. Did not care to look why.
So, I still do not know what exactly the problem is. So for those of you who need to use this pin, I guess you, and everyone else who is using a 4.x kernel will have to load a device tree overlay just for gpio1_16 to work correctly under sysfs. kernels 3.8.x I’m not sure about.
So, what is bothering me about this is that I do not know if this particular problem has been discussed before, and is a known issue or not. To me it truly seems to be a bug, but other than what I’ve done, I know no way of confirming this.
So just to keep things clear. The behavior I talked about above only effects the Beaglebone Green. There is not such issue with the Beaglebone Black. But I do not know why, nor do I know how to correct this.
Shouldn’t this be an important issue ? Or does everyone feel that is should be necessary to configure this pin via a device tree overlay file in order for this 1 pin to be usable ?