GPIO5.2 or BBAI (Rev A1) Cape Pin P9.18b, For Example Won't Read Pin Value Correctly

GoogleGroups
1

Having some trouble understanding what I am seeing, this is probably the simplest thing that I have to tackle right now, after getting just about every other piece of silicon working on the BBAI…a simple, read a GPIO.

I am using devicetrees, and I believe that I have my IO configured correctly from what I see, according to many feedback points:
shiow-pins:
P9.18b 173 slow rx up 14 gpio 4.02 gpio@4805b000 (gpio5)
sysfs

/sys/class/gpio/gpio162
direction: in
value: 0
active_low: 0
edge: none

I want to read this pin accurately.
My oscope shows the pin HIGH at 3V.
Everything else shows the pin LOW.

I am successful with many other pins, however I also have an output that is basically giving me the same grief.

P9.15 69 fast down 14 gpio 2.12 gpio@48057000 (gpio3)

/sys/class/gpio/gpio108
direction: out
value: 1
active_low: 0
edge: none

In this case, as an IO, I can change the value to 1 or 0, and sysfs keeps track of it just fine, but the oscope shows that pin stuck at 0.

Do I need to cut some of the 0-ohm resistors off the BBAI?

I do have the P9.18a pin floating, to not have a contention…

DRA7XX_CORE_IOPAD( 0x36B4, PIN_INPUT_PULLUP | MUX_MODE14 | SLEWCONTROL ) // G12 P9.18b GPIO5-2 Switch2
DRA7XX_CORE_IOPAD( 0x37C8, PIN_INPUT | MUX_MODE14 ) // G17 P9.18a not used, default

Like I said, I have just had amazing luck over the past few weeks with the PRU coding without a debugger, that was a lot of fun, but it is a pretty bad ass core, all 4 of them.

All I want to do now is monitor a switch, and turn on and off an LED! While I am doing that successfully with other pins, these two (there are a few more) just either won’t report the correct value, or not drive the right value.

Any help will keep some hair on my head!

2

Trying to get through the GPIO instantiation into sysfs, and I still cannot control some GPIO, but I have another issue that is perplexing… I have three pins that do not want to come alive in sysfs…

gpio278 gpio8.22 cape P8.30b

gpio272 gpio8.16 cape P8.45b

gpio274 gpio8.18 cape P8.17
– I have checked the TI PinMux too,l good., pins are available and are mapped as I would assume to the GPIO crosspoint
– Device Tree definitions, look good

DRA7XX_CORE_IOPAD( 0x3624, PIN_INPUT_PULLUP | MUX_MODE14 ) // Ball A7 P8.17 gpio8-18
DRA7XX_CORE_IOPAD( 0x3634, PIN_INPUT_PULLUP | MUX_MODE14 ) // B9 P8.30b gpio8_22
DRA7XX_CORE_IOPAD( 0x35CC, PIN_INPUT | MUX_MODE14 ) // B10 P8.30a default
DRA7XX_CORE_IOPAD( 0x361C, PIN_OUTPUT_PULLDOWN | MUX_MODE14 ) // B7 P8.45b gpio8_16 Up square wave output
DRA7XX_CORE_IOPAD( 0x35DC, PIN_INPUT | MUX_MODE14 ) // F11 P8.45a default

– “show-pins” confirms that the pins are defined, and I can make them change via Device Tree .dtb changes, look good
P8.30b 141 fast rx up 14 gpio 7.22 gpio@48053000 (gpio8)

P8.45b 135 fast down 14 gpio 7.16 gpio@48053000 (gpio8)

P8.17 137 fast rx up 14 gpio 7.18 gpio@48053000 (gpio8)

However, when I try to “export” those as gpio pins, they show a write error:

debian@beaglebone:~$ echo 274 > /sys/class/gpio/export
-bash: echo: write error: Invalid argument

Kernel log shows the issue, the GPIO is invalid…
journalctl -k -n10

Jun 13 23:35:43 beaglebone kernel: export_store: invalid GPIO 278
Jun 13 23:35:46 beaglebone kernel: export_store: invalid GPIO 272
Jun 13 23:35:54 beaglebone kernel: export_store: invalid GPIO 274

I still have to go test these all now to see if they work, as I mentioned at the first post, I have lots of pins working as expected, both IN and OUT, but some just do not want to either report the right IN value, stuck at 0, or do not put out electrically the correct state, even though “value” shows it tracking my commands.

One commonality that I see is that these are all on Port8 –
#define PORTSIZE 32
#define GPIOXXX (PORTSIZE * 8) + 22 // gpio278 gpio8.22 cape P8.30b
This is how I generate the gpio number…

ANY pointers here would be great!

3

Sorry for wasting everyone’s time, email hits, packets across the Internet…I am dumb…

That last commonality that GPIO8 always bombed…These are 0 referenced, not 1 referenced.

#define PORTSIZE 32
#define GPIOXXX ((PORTSIZE * 8) - 1) + 22 // gpio278 gpio8.22 cape P8.30b

Subtraction 1 from the group made this work…

4

According to the system manual for the AI (https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual), P8.17 is GPIO 242. It also doesn’t list GPIOs for the B mapping of the other pins (so I don’t know if it’s doable or not), but you have access to other GPIO that are connected to the same cape pin using sysfs. So P8.45 is GPIO 224 (different gpio pin, though gpio8.0) and P8.30 is GPIO 116 (again, different port/pin, gpio4.20). I’m not sure if you can access the b version of those pins using sysfs or not, but you should be able to with libgpiod, using gpioget and gpioset.

5

John,
Thanks for answering, thought I was the only one out there working today…
According to the system manual for the AI (https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual), P8.17 is GPIO 242 <=== shouldn’t that be gpio241?

Figured This Out
Here is why I was going crazy, my first GPIO assignment just happened to be one of these three wrongly mapped pins, all the rest of my pins that I am accessing through sysfs are working, plus I have direct access from the PRUs for the special pins, which is where I have been working for the past few weeks. I was trying to finish this job and had to get some switches and indicator LEDs, resets, etc. to work from the main core, and hence where I was today.

So, out of the 19 pins that I have assigned to sysfs, three of them are not mapped according to the documentation that I have been using, which is the Google Sheet at: https://goo.gl/jiazTL
#define PORTSIZE 32
// Test point 10

#define TP10_OUT (PORTSIZE * 1) + 24 // gpio56 gpio1.24 cape P8.3 - why does this work? - VALIDATED
//#define TP10_OUT (PORTSIZE * 0) + 24 // gpio24 gpio1.24 cape P8.3 - and this does not?
// Test Point 9

#define TP9_OUT (PORTSIZE * 1) + 23 // gpio45 gpio1.23 cape P8.22 - why does this work? - VALIDATED
//#define TP9_OUT (PORTSIZE * 0) + 23 // gpio23 gpio1.23 cape P8.22 - and this does not?
// LED1

#define LED1_OUT (PORTSIZE * 1) + 22 // gpio54 gpio1.22 cape P8.23 – why does this work?? - VALIDATED

//#define LED1_OUT (PORTSIZE * 0) + 22 // gpio22 gpio1.22 cape P8.23 – and this does not work?

These are all on GPIO1 (gpio0…) bank, which just like when I had the issue with trying to access pins above 256, I got sysfs file errors. I did not get file errors on the bad lines, those were mapped to the sysfs gpio structure, but they did not toggle the expected pins, so they are allowable gpioxxx assignments, just don’t know what pin they were assigned to on the BGA.

Right now, I am good to go, that was it for me, but I am still curious where the mapping issue is for GPIO1… The -1 for me fixed the major issues, and these three, after testing each of the 19 pins by hand with an LED and switch, are perplexing but I am moving on. If someone figures this our, post here, thanks!

6

P8.17 is actually gpio8.18, so 242 is correct.

I just checked P8.3, P8.22 and P8.23 using the listed GPIO24, GPIO23 and GPIO22 and they all worked with sysfs. I know I’ve been bitten by there being so many steps that have to happen in order to change the behavior of a pin (having to make changes to the device tree overlay, compile it, copy it to the right place and then reboot for things to take effect, then also export and set the proper direction on the pin). Leaving any step out can lead to a lot of frustration especially when testing several different pins and a minor step was left out for one or two of them. Can’t speak to your specific situation, but me leaving out one of those steps has always been the culprit (except in the case of P9.13, which isn’t actually wired up to a GPIO pin yet).