BBBW and Relay Cape Unbootable After Running LibGPIOD-dev source and kernel -r54

Hello,

I thought it was me. I thought I was creating faulty efforts when building for the Relay Cape on the BBBW SBC.

I use sudo apt update and then run the source which can be found here: boards/capes/relay.rst · main · Seth N / docs.beagleboard.io · GitLab

That is my clone of the Wiki so far.

Anyway, I have not been able to tell if it is the -r54 kernel that is broken or the source for the Relay Cape w/ LibGPIOd-dev/gpiod.h.

Is anyone testing w/ LibGPIOd-dev/gpiod.h?

Seth

P.S. If you can point me to where I am at fault, that would be nice. If indeed it is a -r54 kernel and apt issue, I will bow out for now.

Hello,

Back on Top!

Sorry for the odd headline and full text of this/these short paragraphs.

Outside of being sorry.

  1. Has anyone else seen this gpiod.h directive in a C file create an unbootable instance on the BBBW or BBB w/ the am335x?
  2. I have my TTL to USB cable ready for use. Would an output on my end of the BBBW be of any help?
  3. I did see that the kernel is updated past the -r54 release recently. Has anyone tested C or Python3 w/ gpiod.h/gpiod?

I have not tested Python3 personally for now. I wanted to try C first and get it working. So, I will get back to it and figure out what it is I am missing to get it running through reboots…

What else does gpiod need to handle reboots on the BBB/BBBW?

For instance…in Python3:

import gpiod
from time import sleep

...

# Extra source everywhere

Anyway, here is the C file to review in case you have time to review it and make it a consideration.

    /*
    Simple gpiod example of toggling a LED connected to a gpio line from
    the BeagleBone Black Wireless and Relay Cape.
    Exits with or without CTRL-C.
    */

    // This source can be found here: https://github.com/tranter/blogs/blob/master/gpio/part9/example.c
    // It has been changed by me, Seth, to handle the RelayCape and BBBW Linux based SiP SBC.

    // kernel: 5.10.140-ti-r52
    // image : BeagleBoard.org Debian Bullseye Minimal Image 2022-11-01

    // type gpioinfo and look for this line: line 20: "P9_41B" "relay1" output active-high [used]
    // That line shows us the info. we need to make an educated decision on what fd we will use, i.e. relay1.
    // We will also need to locate which chipname is being utilized. For instance: gpiochip0 - 32 lines:

    // #include <linux/gpio.h>
    #include <gpiod.h>
    #include <stdio.h>
    #include <unistd.h>

    int main(int argc, char **argv)
    {
        const char *chipname = "gpiochip0";
        struct gpiod_chip *chip;
        struct gpiod_line *lineLED;

    int i, ret;

    // Open GPIO chip
    chip = gpiod_chip_open_by_name(chipname);
    if (!chip) {
        perror("Open chip failed\n");
        return 1;
    }

    // Open GPIO lines
    lineLED = gpiod_chip_get_line(chip, 20);
    if (!lineLED) {
        perror("Get line failed\n");
        return 1;
    }

    // Open LED lines for output
    ret = gpiod_line_request_output(lineLED, "relay1", 0);
    if (ret < 0) {
        perror("Request line as output failed\n");
        return 1;
    }

    // Blink a LED
    i = 0;
    while (true) {
        ret = gpiod_line_set_value(lineLED, (i & 1) != 0);
        if (ret < 0) {
            perror("Set line output failed\n");
            return 1;
        }
        usleep(1000000);
        i++;
    }

    // Release lines and chip
    gpiod_line_release(lineLED);
    gpiod_chip_close(chip);
    return 0;
    }

In my mind here, I think this source runs for the Relay Cape. I believe it is an additional requirement that is needed to alter C files w/ cmake and the gpiod.h directive.

No matter what, I am going to keep trying.

I know what people may feel about the transition and sysfs to another route of methods and fd’s.

Argh, right? Or…wozzers. Somethin new? Either way, boring or exciting on your end, give feedback on how I can help you help this rendition, please.

Seth

P.S. I got so happy when the file in question, that above C file, did not float the pin after running and then ending. Then, brrrrt. The BBBW and Relay Cape attached would not boot. This threw me a curve ball of sorts. Happy, unknowledgeable, and then anger. I was angry b/c I could not describe what was taking place or for what reasons it was taking place. Anyway, back to the old grind of wheels and gears for now. BBB!

This is the bit that is supposed to close the line and chip that was requested.

// Release lines and chip
    gpiod_line_release(lineLED);
    gpiod_chip_close(chip);
    return 0;
    }

Obviously, from the comment, this bit of source handles the release and close. I was thinking that this had some peculiar functionality in the GPIO pin assignment. I should check the .dts file for the Relay Cape again. Thank you for reading. Please reply!

Update

I think this link will describe to me what is exactly taking place when it is being built w/out my compilation of misguided queues. libgpiod/libgpiod.git - C library and tools for interacting with the linux GPIO character device

Anyway…off to flash yet another build from beagleboard.org … Updates on the way for anyone willing to read or reread my blast of a chatterbox posting.

Update

I broke it:

  1. The relay1 had nothing attached to the relay1.
  2. I ran the source and heard the click.
  3. W/out something being attached to the Relay Cape outside of the BBBW or BBGW, hilarity ensues.

Seth

P.S. Not so funny now but it was fun trying to figure it out.

So…

If you use the Relay Cape or any Cape for that matter, use a Power Supply of some sort or attach a module or LED first.

Do not run your source w/out something attached just to see the LED onboard and to hear the click.

Blah.