GPIO pin number confusion

groumpf

Hi, to deal with my OLED screen I need to use a GPIO pin to deliver the RST signal to my screen at startup.

I read https://learn.bela.io/using-bela/technical-explainers/other-uses-of-gpio-pins/ on how to find an available pin.

When crossing the information on the diagrams with some github information I understood I could use both P8_13 or P8_14 for my need. I then tried to use config-pin to configure P8_13 as output, but I think it broke my config, as after running config-pin P8.13 out nothing works

Now when I try to run any program I get this error before even calling setup :

Copying new source files to the board...using rsync...
Building and running project...
Running /root/Bela/projects/src/src --mux-channels 4 --analog-channels 32
Failed to open PRU driver
Segmentation fault

When I look at the P8 table I think I might have typed the wrong pin number for config-pin as the P8_10 (related to pru) has the $PINS value set to 13.

Here are my questions :
- Which pin number am I supposed to use with config-pin to configure P8_13 ? P8.10 ? If that's the case IMHO the documentation about finding pins and configure them is not clear enough about this confusing step
- How could I fix my build ? I tried to reset P8.13 to default but it still wont work. I could reinstall my whole Bela firmware but it would take some time as I need to reconfigure UART, c++14 support and so on...

Thanks in advance, have fun folks 🙂

groumpf

EDIT : I tried reflashing the eMMC and I found more about my issue :

1) config-pin P8.13 out does not seems to be causing the issue as I still have it without calling it

2) The issue seems to come from the modifications I made to /mnt/boot/uEnv.txt
To enable the use of config-pin I added a new line to my device tree overlay as suggested here : https://learn.bela.io/using-bela/technical-explainers/device-tree-overlays/#config-pin

So my uEnv.txt looks like that :

[...]
uboot_overlay_addr2=/lib/firmware/BB-BELA-00A1.dtbo
uboot_overlay_addr3=/lib/firmware/BB-BELA-CTAG-SPI-00A0.dtbo
uboot_overlay_addr4=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/cape-universala-00A0.dtbo

The last line is causing the issue, as I don't have the PRU driver failed error when removing it. Although I need this to be able to use config-pin to use a new GPIO.

Any ideas of what I'm doing wrong ?

giuliomoro

It's not explained well on that page, but you do need some cape-universal overlay for config-pin to work on the BeagleBone. Let me have a closer look.

giuliomoro

but that itself is not straightforward because of some pin conflicts that I don't seem to be able to eliminate using the same technique that works on PocketBeagle ....

giuliomoro

groumpf So I think I'll use this one. However I do have a question, in the HeaderTable, 0x17 is marked as OUTPUT GPIO(mode7) 0x17 pullup.

Does it make sense to have an output pin pulled high ? I thought it was only usefull when using it as input to avoid shortcircuit-ing the board.

These are the actual settings available for a pin (beside the bits that set which signal is mapped out to it):

alt text

"OUTPUT" is not really a setting: all pins can work as ouputs. Some can have "receiver active", which is required if you want them to work as an input. In both cases you can have a pullup enabled or not. Point is even when a GPIO signal is connected to the pin, it doesn't mean that the GPIO itself will always be driving the pin high or low, in fact it will default to a high-impedance state first. When you later interact with it via the GPIO driver (/sys/class/gpio), you can set its direction (in,out) and if it's an output, you can set its value. The pullup/pulldown as set by the pinmuxer is enabled early on in the boot process and it is only effective until the moment you enable the GPIO via the driver and actively write an output to it. Once you start writing to it, while the pullup/pulldown resistor will still be electrically connected, it won't affect the voltage output of the pin. These resistors are typically in the tens of kiloohm range, so they draw a negligible amount of current, so much that for some applications they are not enough and you may require an external pullup/pulldown anyhow (e.g.: i2c bus).

giuliomoro but that itself is not straightforward because of some pin conflicts that I don't seem to be able to eliminate using the same technique that works on PocketBeagle ....

getting there ...

Ward

I'm also using an OLED display that per datasheet requires a reset line to be connected. However I've wired the reset to 3.3V and it works fine. For my display, the reset is only used at booting the device, and if you don't mind the display flickering for like 100ms once it starts up, you can probably live without connecting the reset pin to a GPIO and just pulling it up or down.

groumpf

Ward Oh ok, nice to know, thanks 🙂 I'll try it then

groumpf

Ok thanks !

To avoid having to use config-pin I looked into the pinmuxer configuration, and it looks like P8_17 is already configured as a GPIO output and is not used by bela.

root@bela:~# grep 82c $PINS
pin 11 (PIN11) 44e1082c 00000017 pinctrl-single

So I think I'll use this one. However I do have a question, in the HeaderTable, 0x17 is marked as OUTPUT GPIO(mode7) 0x17 pullup.

Does it make sense to have an output pin pulled high ? I thought it was only usefull when using it as input to avoid shortcircuit-ing the board.

giuliomoro

ok done. You'd need to get this branch on your board: https://github.com/BelaPlatform/bb.org-overlays/tree/bela-bbb-cape-universal , then do make all install . At that point you should be able to load cape-universalh (that one specifically, no other cape-universal* ones).

For instance, your uEnv.txt should contain:

uboot_overlay_addr1=/lib/firmware/cape-universalh-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-BELA-00A1.dtbo

Then you will be able to use config-pin on most of P8/P9 pins that are not required for Bela's core to function.

I'd appreciate it if you could test it.

groumpf

Ok thanks a lot for the dev time 🙂 Unfortunately I won't be able to test it for a few days (gotta prepare for a job interview), but I'll let you know when I'll test it !

Also, is it compatible with these other overlays ?

uboot_overlay_addr3=/lib/firmware/BB-BELA-CTAG-SPI-00A0.dtbo  # dont know what it's for but it was there
uboot_overlay_addr4=/lib/firmware/BB-UART4-00A0.dtbo          # needed for my MIDI DIN-5 port

giuliomoro

groumpf Also, is it compatible with these other overlays ?

I think you need to remove them both but you don't have actually need them. The CTAG one is only needed if you have a ctag card. The UART4 one is sort of already included in cape-universalh, though not you may have to use the config-pin to enable the specific pins for tx and Rx

groumpf

[Sorry I first posted this in the wrong topic, my bad]
Hello there, back from the dead

I did found a solution for my use case without needing config-pin
(I used P8_17 which is already configured well for my case).

I saw this topic was mentioned in another topic, do you still need me to test the overlay on the dev branch you posted to see how it works ? Or did the other person tested it enough ?

Let me know, I'd be glad to help

giuliomoro

I don't think there's hard need for you to test it, thanks. Let's see if @Laimonade comes back with any issues.

Laimonade

@giuliomoro Thank you, the technique you mentioned above seems to be working! Bela boots up when I include cape-universalh overlay and I can call config-pin without issues! Summary of the steps for others:

Clone on Bela the bela-bbb-cape-universal branch from this repo.
cd into the cloned directory and make all install in the Bela terminal.
Add the overlay by adding this line uboot_overlay_addr1=/lib/firmware/cape-universalh-00A0.dtbo in uEnv.txt (located in the BELABOOT partition).

See more about device tree overlay's https://learn.bela.io/using-bela/technical-explainers/device-tree-overlays/