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...* On Saturday, June 13, 2020 at 4:53:01 PM UTC-7 jimvr 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/284282e2-76cd-4793-acba-89105841906fn%40googlegroups.com.
