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 <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p8.20-p8.22>), 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! On Saturday, June 13, 2020 at 5:11:14 PM UTC-7 [email protected] wrote: > According to the system manual for the AI ( > https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual > <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p8.20-p8.22>), > > 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. > > On Jun 13, 2020, at 5:53 PM, jimvr <[email protected]> wrote: > > 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!* > > On Friday, June 12, 2020 at 6:28:33 PM UTC-7 jimvr wrote: > >> 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! >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/3c4123a0-e883-4b6e-a3dd-a42cea4c3a07n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/3c4123a0-e883-4b6e-a3dd-a42cea4c3a07n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f4f633a3-bf52-49c0-b58f-bc420b0f8dc1n%40googlegroups.com.
