Using P8_11 as digital input with internal pull up enabled

General Discussion
1

Hi,

I have been trying to configure p8_11 as digital input with internal pull up. I am using BBB rev C and followed different examples; even I used the dts generating tools, then compile it to create dto and then put it into uenv.txt but it seems after boot up it does not enable the pullup. If I use a 10k external pullup, it works fine though.
I looked at the schematic and did not notice any other circuit pulling that pin low.
I appreciate your help in resolving this issue.
Thank you in advance!

2

Try

/boot/uEnv.txt

LINUX file names are case-sensitive.

Regards

3

Thank you!
You are correct, and I used uEnv.txt. I wrote it wrong in my text. This is what I did in a bit more details:

Following instructions in BeagleBone Black Device-Tree Overlay Generator
I generated the .dts file for P8_11 defined as GPIO1_13, input, with pull-up.

bspm_P8_11_37-00A0.dts file content is:

/*

  • This is a template-generated file from BoneScript
    */

/dts-v1/;
/plugin/;

/{
compatible = “ti,beaglebone”, “ti,beaglebone-black”;
part_number = “BS_PINMODE_P8_11_0x37”;

exclusive-use =
    "P8.11",
    "gpio1_13";

fragment@0 {
    target = <&am33xx_pinmux>;
    __overlay__ {
        bs_pinmode_P8_11_0x37: pinmux_bs_pinmode_P8_11_0x37 {
            pinctrl-single,pins = <0x034 0x37>;
        };
    };
};

fragment@1 {
    target = <&ocp>;
    __overlay__ {
        bs_pinmode_P8_11_0x37_pinmux {
            compatible = "bone-pinmux-helper";
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&bs_pinmode_P8_11_0x37>;
        };
    };
};

};

Then I used the following command to compile it and generate .dtbo file

dtc -O dtb -o /lib/firmware/bspm_P8_11_37-00A0.dtbo -b 0 -@ /lib/firmware/bspm_P8_11_37-00A0.dts

I could not follow the rest of the instruction stated in that page since my BBB does not have bone_capemgr folder. If I am not wrong, I read that after a certain Debian kernel version on, they do not offer that folder structure.
So, instead I added the path to generated .dtbo in /boot/uEnv.txt, as shown below:

I made sure the following lines are in the uEnv.txt
…
###Master Enable
enable_uboot_overlays=1
…
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/bspm_P8_11_37-00A0.dtbo

The result is that P8_11 does not seem to have internal pull-up enabled. When I read the pin value in /sys/class/gpio/gpio45 it reads ‘0’ (low) and if I pull it up externally it reads ‘1’.

Thanks

4

Have you tried 0x17 instead of 0x37 ?

No idea what the receiver enable bit does, but it might be overriding the pullup in some way.

5

This bit determines input or output state.

@Sia
Do you load cape-universal blob? (This may override your setting, or block it since the pin is claimed.)

I don’t deal with such stuff. Instead I use the in-source pinmuxing feature of libpruio.

Regards

1 Like
6

Thank you DTJF and Benedict!
Your comments helped me and I think I have fixed it now. I explain it here, although it might not be precise enough.
Using that DTS generator website, as long as I create only one dts and test them one at a time, it works fine. (Note that as DTJF said, we should not enable cape_universal).
The problem arises when I create two .dts, and consequently its .dtbo file, for two different GPIOs, e.g., P8_11 and P8_13. What I was doing wrong was that I put them in uEnv.txt one after another, like shown below:
dtb_overlay=/lib/firmware/bspm_P8_11_37-00A0.dtbo
dtb_overlay=/lib/firmware/bspm_P8_13_37-00A0.dtbo
This made none of them work! I do not know the reason though.

Then I tried to combine them all in one .dts. I did miss one part and it was in this part:

exclusive-use =
“P8.09”,
“P8.11”;

It does not work this way, I had to add a couple of more lines under this related to the gpio numbers. This is what I did and worked for me:

exclusive-use =
“P8.09”,
“P8.11”,
“P8.13”,

	/* the hardware IP uses */
	"gpio1_13",
	"gpio0_23";

I got the idea from the following link:

I hope it works as I add the rest of the GPIOs to it.

Cheers,

7

Not seen that website to generate overlay files. Shame there is no date on it to show when it was last updated.

I have never used ‘fragment’ or ‘__overlay__’ when writing overlay files, and none of the official BBB overlays use them it seems either.

Also it seems a pretty good idea to add something like this, which is done by the official overlays.

&{/chosen} {
        overlays {
                YOUR_CUSTOM_NAME_HERE.kernel = __TIMESTAMP__;
        };
};

You can then check easily to see if the overly gets loaded by doing

 ls /sys/firmware/devicetree/base/chosen/overlays/
1 Like
8

There’s a dts source generator creating pinmuxing files and compiling them to /lib/firmware. After setting some meta data, specify the desired modes like

M(P8_11) = CHR(7 + PU)  ' example: pin 11 at header P8 in mode 7 (Gpio) as input (pull-up resistor)
M(P8_13) = CHR(7 + PU)  ' example: pin 13 at header P8 in mode 7 (Gpio) as input (pull-up resistor)

and finaly compile the code and execute it as admin (for write access in /lib folder).

Find a description at libpruio: src/config/dts_custom.bas File Reference

Regards

1 Like