GPIO50 file/directory deleted

lranders · June 25, 2024, 3:34pm

But yes, Robert is right; you should always use something along the lines of:

A LED is way to power-hungry to drive directly from a GPIO pin on the AM335x processor.

Jcal · June 25, 2024, 3:45pm

Have 220Ω resistor in series with (1.2-2.1) volt LED (Max current 20mA)

R=(3.3V-2.1V)/6mA=200Ω

lranders · June 25, 2024, 3:47pm

Yes, you’ll be overloading that poor pin that way.
The drive strength can’t be more than 4 to 8mA; hence the transistor.

There’s a reason why the BBB is made this exact way:

Jcal · June 25, 2024, 3:49pm

Will see if school lab has a 2N2222A or similar Transistor and try this circuit (It works on Multisim).

lranders · June 25, 2024, 3:52pm

Yes, that looks a lot better!

Jcal · June 27, 2024, 12:16am

root@BeagleBone:/home/debian# cat /etc/debian_version
11.9
root@BeagleBone:/home/debian# uname -a
Linux BeagleBone 5.10.168-ti-r77 #1bullseye SMP PREEMPT Wed Feb 28 21:05:58 UTC 2024 armv7l GNU/Linux

Before connecting the following circuit to BBB, it was tested using a dual Power supply. Ammeters showed base current of 300μA and LED current of 3.3mA. The LED is ratted 1.7v-2.1V. The circuit shown is a Multisim simulation of the test.

Connected the circuit to BBB (Powered via USB). Did the following:

   root@BeagleBone:/home/debian# ls /sys/class/gpio/gpio50
    active_low  device  direction  edge  label  power  subsystem  uevent  value
    root@BeagleBone:/home/debian# cat /sys/class/gpio/gpio50/label
    P9_14
   root@BeagleBone:/home/debian# cat /sys/class/gpio/gpio50/value
   0
   root@BeagleBone:/home/debian# gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1

The LEB Blinks once.

But:

root@BeagleBone:/home/debian# ls /sys/class/gpio/gpio50
  ls: cannot access '/sys/class/gpio/gpio50': No such file or directory
  root@BeagleBone:/home/debian# gpioget $(gpiofind "P9_14 [ehrpwm1a]")
 0

Subsequent:

gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1

Do not blink the LED. Must power off and reboot to get LED to blink.

Questions:
1. Why is the gpio50 directory disappearing?
2. Why can't the LED be turned on more than once without rebooting?

My goal is to turn the LED off and on using C/C++. This was a preliminary test to see, if the circuit worked on the BBB. It kind-of works but there are issues that I do not know how to resolve.

RobertCNelson · June 27, 2024, 12:18am

Just to clarify 1 = on, 0 = off…

Turn LED on:
gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1

Turn LED off:
gpioset $(gpiofind "P9_14 [ehrpwm1a]")=0

Regards,

Jcal · June 27, 2024, 12:21am

Yes: 1 is ON and 0 is OFF.
As stated the LED blinks once and will not blink again unless the BBB is rebooted. Once rebooted the gpio50 directory reappears and the LED can be blinked by

gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1

RobertCNelson · June 27, 2024, 12:22am

So if you want it to blink:

gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1
sleep 5
gpioset $(gpiofind "P9_14 [ehrpwm1a]")=0
sleep 5
gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1
sleep 5
gpioset $(gpiofind "P9_14 [ehrpwm1a]")=0

Or not?

gpioset also has a timer…

gpioset --mode=time --sec=1 $(gpiofind "P9_14 [ehrpwm1a]")=1

Regards,

Jcal · June 27, 2024, 12:29am

Had to reboot: The first

gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1

blinks LED once, remaining have no effect.

RobertCNelson · June 27, 2024, 12:33am

okay, i’ll take a look later, it should…

can you also try:

config-pin p9.14 gpio

(and it should be gpio by default, so that probably doesn’t do anything…)

Jcal · June 27, 2024, 12:34am

Thank you for you patience and help.
Will try the timer and the config when system reboots
Regards
JC

Jcal · June 27, 2024, 1:07am

Did the following:

root@BeagleBone:/home/debian# config-pin p9.14 gpio

Current mode for P9_14 is:     gpio

root@BeagleBone:/home/debian# gpioset --mode=time --sec=1 $(gpiofind "P9_14 [ehrpwm1a]")=1
root@BeagleBone:/home/debian# gpioset --mode=time --sec=1 $(gpiofind "P9_14 [ehrpwm1a]")=1

The LED turned on for 1 second twice It did the same on subsequent repeats of the gpioset command

Powered off BBB and rebooted. Did not issue the config-pin command. Tried:
debian@BeagleBone:~$ gpioset --mode=time --sec=1 $(gpiofind "P9_14 [ehrpwm1a]")=1

The LED turns on for 1 second and turns off every time I repeat the command. But:

gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1

does nothing.

The LED will light (turn ON/OFF) by setting a time, but will not light there is no time set.

Again, the gpio50 directory keeps disappearing.

debian@BeagleBone:~$ ls /sys/class/gpio/gpio50
active_low  device  direction  edge  label  power  subsystem  uevent  value
debian@BeagleBone:~$ gpioset --mode=time --sec=1 $(gpiofind "P9_14 [ehrpwm1a]")=1
debian@BeagleBone:~$ ls /sys/class/gpio/gpio50
ls: cannot access '/sys/class/gpio/gpio50': No such file or directory

Thanks and regards
JC

silver2row · June 27, 2024, 1:49am

I was having this issue too.

The BBB shows /sys/class/gpio/* where * is the listing of files available for GPIO pins allocated to the headers from the am335x.

config-pin is not listed as available on Bookworm but it is around for the Bullseye image(s).

Um…

Sometimes the, for instance, gpio45 file would be around and then disappear if I was to use libgpiod-dev via gpiod.h and also for Python3 source as gpiod as an import into the .py file.
Rebooting made the file reappear.
I could not configure /sys/class/gpio/gpio45 at all along with other gpio files like gpio44 during execution when using source even with sysfs.

Seth

P.S. If you guys get it going and have it working at some point, my reason for saying so here, I would like to know.

lranders · June 27, 2024, 4:51am

This is only wild speculation, but would it stand to reason that the PWM driver is fighting
with the GPIO system for control of the pin?

The reason why I’m dubious is that:

It’s clamed by something in the system; [used]
My BBGW doesn’t show [ehrpwm1a] but GPMC_A2.

I am using an older kernel though, so that could be why…
BeagleBoard.org Debian Buster Console Image 2020-04-06

I can confirm that my gpio50 directory disappears immidiately
after doing gpioset 1 18=1 and gpioset 1 18=0,
so whatever this is, it’s not just @Jcal or @silver2row…

Once the directory is gone, I can re-export it with:
echo 50 > /sys/class/gpio/export, so a reset is not required.

silver2row · June 27, 2024, 5:00am

@lranders ,

Hello There…

libgpiod-dev and gpiod had some errors early on with the Buster images, i.e. there was a way to use them, stop the GPIO pins, and then reuse them in the same terminal session.

But, the GPIO was held HIGH no matter what the source stated.

Seth

P.S. It is a mesh of differences depending on which kernel and image was used back in Buster and early on with Bullseye. Just history there in case people were wondering. Either way, I am not so much complaining but trying to make some motor movement out of the GPIO(s) in question along with PWM peripherals if necessary.

So, with the GPIO held HIGH, a reboot was necessary to relieve the GPIO or module in this case with me and motors so that access was regranted back after a HIGH to LOW to a except KeyboardInterrupt or a system exit.

Update

Also, I will be working on the eQEP peripherals soon to alter motors. Once I finalize the set up, I will update with a separate post.

Jcal · June 27, 2024, 1:38pm

Back on June 25 lranders wrote:

 If you do the `gpioinfo` I got the feeling it’s going to show a `[used]` next to it, which should mean that one of your loaded overlays has claimed it already; ADC maybe?

I did some research and found: Accessing More I/O @beagleboard.org. It describes how to free header pins by modifying the /boot/uEnv.txt; specifically the HDMI video overlay and the audio overlay. I edited the uEnv.txt and uncommitted the following two lines:

   disable_uboot_overlay_video=1
   disable_uboot_overlay_audio=1

Saved the file and rebooted. Pin P9-14 is on chip 1.

Prior to the change to uEnv.txt file and reboot gpioinfo 1 showed the following:

         line 18: "P9_14 [ehrpwm1a]" "P9_14" input active-high [used]

After the change to uEnv.txt and reboot gpioinfo 1 still shows:

         line 18: "P9_14 [ehrpwm1a]" "P9_14" input active-high [used]

Actually gpioinfo for chips 0, ,1, 2, and 3 after the change to uEnv.txt is exactly the as before the change.

From what I have read (still trying to understand it all), gpio is based upon The New Character Device Idea?. The two lines in uEnv.txt are part of the depreciated overlay paradigm (https://www.kernel.org/doc/Documentation/gpio/sysfs.txt).

So am I correct in thinking that:

Disabling the two overlays has no effect on GPIO
gpioinfo is reading a database and does not reflect the actual status of the pin at the time of invocation.

Also once set to 1 via command gpioset $(gpiofind "P9_14 [ehrpwm1a]")=1 shouldn’t pin P9_14 stay high until the command gpioset $(gpiofind "P9_14 [ehrpwm1a]")=0. When I did my testing P9_14 would immediately return to 0 after being set to 1.

lranders · June 27, 2024, 1:49pm

Yes, I think it’s pretty safe to say that the pin names are controlled by device-tree.

I’m not speaking with complete authority here, but I believe we’re seeing the proof
that two different processes are at play here at the same time.

Case and point:

Jcal · June 27, 2024, 1:57pm

So where can I look for information to try resolve the conflicts. Also have come across the following:

ibgpiod - C library and tools for interacting with the Linux GPIO character device.

lranders · June 27, 2024, 2:35pm

It’s hard to give any concise answer here, because the topic is so vast, but what I would do is,
first grab the schematic and see what ball P9_14 goes to.

Armed with that information, I would mow through the AM335x TRM to see what possible
functions it provides; which can be many; this is where the PINMUX comes in.

The PINMUX is normally controlled by the device-tree, so that’s where I’d be heading next.
When in doubt, the running device-tree can be dumped like this:
dtc -I fs /sys/firmware/devicetree/base
Look for any clues to the name you got from gpioinfo.

In case you were wondering, the device-tree repository is here:
https://openbeagle.org/beagleboard/BeagleBoard-DeviceTrees.git
There is an enormous amount of information stored here…

Please note that all of this is highly dependent on your Linux kernel build
and can change quite violently, even between comparatively close versions.