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.
