Problem reading input pin P8_22

General Discussion
1

For reference, uname -r → 6.18.33-bone36

I’m trying to use P8_22 as an input. It is normally used by the eMMC overlay which I’ve disabled in /boot/uEnv.txt. Calling gpioinfo | grep “P8_22” shows that it is an input. If I apply 3.3V or 0V to the pin and query its value using gpiod, I always get INACTIVE. gpiod also reports that it is configured as an input. I wondered if I had damaged this pin, so I tried the same with P8_23 (also normally used by the eMMC) and got the same result.

I then went into /opt/source/BeagleBoard-DeviceTrees/src/arm/overlays and edited BB-BONE-eMMC1-01-00A0.dtso to make one of the lines read:

AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE7)

where it used to say MUX_MODE1. Mode 7 I believe is gpio looking at the datasheet. I used the build_n_install.sh script to compile all the overlays and installed them, removed the disable emmc line from uEnv.txt, rebooted, and still can’t get the reported input value on P8_22 to change. What am I missing?

2

An idea would be to take a peek at the PINMUX register with devmem2
to verify that the expected value correspond with reality.

3

Good idea, I looked at the GPIO_OE register (offset 0x134 from GPIO1 base address of 0x4804_C000) and bit 5 is set (the pin is gpio1[5]) indicating it is configured as an input. In fact, bits 0-7 are set. I also looked at GPIO_DATAIN at offset 0x138 and confirmed that bit 5 is cleared. I tried putting 3.3V on the other pins corresponding with bits 0-8 and see no change on bits 0-7 in GPIO_DATAIN.

4

Yea, my left eye always starts twitching slightly when people write about
how they connect pins to 3.3V / GND; hopefully you’re doing that
through a 120 or so ohms resistor to avoid potential damage to them.

1 Like
5

I use the exact same line as that to configure P8_22. But before that in the .dtso, previously I wasn’t sure if this did anything but at root level, before all the other pin config blocks, I added:

&ocp {
    P8_22_pinmux { status = "disabled"; };
}

dtc has some supporting inspection commands too, almost Devicetree decompilers, that can be used to view what was actually loaded.

Overall, I added another block to improve one of the line names too, but my file looks something like:

&ocp {
    P8_22_pinmux { status = "disabled"; };
}

&am33xx_pinmux {
    P8_gpio_pins: pinmux_P8_GPIO_pins {
        pinctrl-single,pins = <
            AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE7)
        >;
    };
};

&{/} {

    p8_gpio_pins {
        compatible = "gpio-leds";
        pinctrl-names = "default";
        pinctrl-0 = <&P8_gpio_pins>;

    };
};
1 Like
6

I appreciate the response, the dtc command was a worthwhile rabbit hole. I tried to swap beaglebones to see if I had just damaged that pin, but ran into another issue with HDMI in that process. I’ll continue trying once that’s resolved. Thanks.

1 Like
7

The last block in your example was the difference, now it works! Thank you.

1 Like
8

It’s crazy how many people struggle with this cryptic device tree overlay system. In my opinion it’s overly complicating a simple system. There is a much easier device driver system afloat with a simple text file that does it all. Writing to a hardware memory address is a simple thing.

9

You’re right. In microcontroller land, things tend to be a lot easier when it’s just you.

Once you introduce multi-tasking/-threading, things start getting interesting.

The whole reason for device-trees were to avoid having to compile kernels all the time.

I’m not saying DT’s are “the magic bullet”, it’s just currently the best approximation we got.
The only reason they’re cryptic is because people keep treating them as such.
To me, they’re about the same as C. You compile them and they do stuff; it really is that simple.

10

Instead you have to compile poorly documented cryptic device tree overlay files that report no errors on startup. A much easier system would allow the user to write directly to hardware then exit, no problem there. Drivers can then be developed in user space. https://forum.beagleboard.org/t/am335xussetpm-user-space-device-driver