BeagleY-AI and GPIO Pins

I will test it.

Thank you.

P.S. I tried the GPIO12 and so on with the GPIO pins and never got far. I will reattempt it all.

oh…

update here…

So, this is what I have currently on my BeagleY-AI:

BeagleY-AI and gpiochip and "Hat" Wiring...

(11 physical pin) to 13 on the "Hat" which is gpiochip2, pin 18
(13 "          ") to 19 on the "Hat" which is gpiochip2, pin 12
(15 "          ") to 12 on the "Hat" which is gpiochip2, pin 16

I hope that makes some sense. Do you think that is correct or should I play pin for pin in the assignment?

I have wires connecting the “Hat” to the BeagleY-AI and not a direct-full connection on the headers.

@Illia_Pikin , yes. I read it. I read the Wiki and keep reviewing it for missed items that may have gone with the many reads.

But, maybe this time I will try to connect the entire “Hat” to the headers of the BeagleY-AI. Give me time. I actually bent the headers already and need to perform some bending…

If memory is correct the logic is inverted on the aiy. Test code we ran on BBB and competitors board was fine. On the aiy it was reversed, was it my fault on our custom overlay??? just added some logic to invert and it was fine.

If you have a scope use that and a 4.7k pull resistor and see what is actually going on.

1 Like

Have looked through all the code you mentioned - “enable” was used there as active high, not active low.

1 Like

I will test soon.

Thank you.

I will test soon.

Seth

P.S. Thank you again.

What is the exact image you are running?
Are the pins you are trying to drive, the out of the box device tree?

UPDATE:
Trying to replicate your setup. This is 12.7 and xfce
One of our bby does not want to run. I have another one and will see if that one still works.


U-Boot SPL 2023.04-g93735daa (Aug 29 2024 - 22:05:30 +0000)
SYSFW ABI: 3.1 (firmware rev 0x000a '10.0.1--v10.00.01 (Fiery Fox)')
SPL initial stack usage: 17048 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed
Authentication passed
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.11.0(release):v2.11.0
NOTICE:  BL31: Built : 22:05:30, Aug 29 2024
I/TC: 
I/TC: OP-TEE version: 4.3.0 (gcc version 12.2.0 (Debian 12.2.0-14)) #1 Thu Aug 29 22:05:30 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 3.1 (firmware rev 0x000a '10.0.1--v10.00.01 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2023.04-g93735daa (Aug 29 2024 - 22:05:30 +0000)
SYSFW ABI: 3.1 (firmware rev 0x000a '10.0.1--v10.00.01 (Fiery Fox)')
Trying to boot from MMC2
Authentication passed
Authentication passed


U-Boot 2023.04-g93735daa (Aug 29 2024 - 22:05:30 +0000)

SoC:   J722S SR1.0 HS-FS
Model: BeagleBoard.org BeagleY-AI
DRAM:  2 GiB (effective 4 GiB)
Core:  104 devices, 28 uclasses, devicetree: separate
MMC:   mmc@fa00000: 1, mmc@fa20000: 2
Loading Environment from nowhere... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc1 is current device
SD/MMC found on device 1
Failed to load 'boot.scr'
Failed to load 'uEnv.txt'
MMC Device 0 not found
no mmc device at slot 0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
BeagleY-AI microSD (extlinux.conf) (swap enabled)
1:	microSD (production test)
2:	transfer microSD rootfs to NVMe (advanced)
3:	microSD (debug)
4:	microSD (default)
Enter choice: 4:	microSD (default)
Retrieving file: /Image
append: console=ttyS2,115200n8 root=/dev/mmcblk1p3 ro rootfstype=ext4 resume=/dev/mmcblk1p2 rootwait net.ifnames=0 quiet
Retrieving file: /ti/k3-am67a-beagley-ai.dtb
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
   Loading Device Tree to 000000008ffe4000, end 000000008ffff1e4 ... OK
Working FDT set to 8ffe4000

Starting kernel ...

I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
I/TC: Secondary CPU 2 initializing
I/TC: Secondary CPU 2 switching to normal world boot
I/TC: Secondary CPU 3 initializing
I/TC: Secondary CPU 3 switching to normal world boot
I/TC: Reserved shared memory is enabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
[    1.290503] rtc-ds1307 2-0068: hctosys: unable to read the hardware clock
[    1.503113] omap8250 2860000.serial: Failed to create device link (0x180) with regulator-3
[    2.676258] debugfs: Directory 'pd:249' with parent 'pm_genpd' already present!
[    2.683695] debugfs: Directory 'pd:248' with parent 'pm_genpd' already present!
[    2.691070] debugfs: Directory 'pd:247' with parent 'pm_genpd' already present!
[    2.698581] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
[    2.705961] debugfs: Directory 'pd:244' with parent 'pm_genpd' already present!
[    2.715327] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
[    2.722700] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
[    2.765128] mmc1: error -110 whilst initialising SD card
[    2.869933] mmc1: error -110 whilst initialising SD card
[    2.974301] mmc1: error -110 whilst initialising SD card
[    3.096991] mmc1: error -110 whilst initialising SD card


Linux beagle 6.1.83-ti-arm64-r64 #1bookworm SMP PREEMPT_DYNAMIC Fri Sep  6 21:31:20 UTC 2024 aarch64 GNU/Linux
BeagleBoard.org Debian Bookworm Xfce Image 2024-09-04

There is everything…

Seth

@Illia_Pikin ,

Okay and so, I cannot use your source either.

I have running source that should do the job, i.e. hence the circular looping in my thought processes for now.

Seth

P.S. I will bend the pins and return service once the “Hat” is fully assembled on the BeagleY-AI.

I ordered a few SD cards, that bby board I grabbed is flaky and only plays with a specific SD card. When they arrive I will load it up on your setup.

1 Like

if you understand the base image, kernel, and source, yes sir.

Please do…

I know there is something I am missing.

Seth

Hi Seth,

I tried your c code that you posted on the 2nd of November, and it’s basicly working fine. I had to fix some minor issues, my changes are shown below.
Checking the pins, I could see the rising and falling levels on the Direction, Step and Enable pins - pins 35, 33 and 32 on the 40 pin header.

This means that the gpios and libgpiod are working as they should.

Double check the sense of your outputs - in particular the enable signal is active low.

I’m on Debian Bookworm Xfce Image 2024-06-12

/*
 * cc gpio_test.c -lgpiod -o gpio_test
 */

#include <gpiod.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>


#ifndef CONSUMER
#define CONSUMER  "Consumer"
#endif


int main(int argc, char **argv)
{
  const char *chipname = "gpiochip2";
  unsigned int line_num1 = 18;		// Direction
  unsigned int line_num2 = 12;		// Step
  unsigned int line_num3 = 16;		// Enable
  unsigned int val;
  struct gpiod_chip *chip;
  struct gpiod_line *line1;
  struct gpiod_line *line2;
  struct gpiod_line *line3;
  int ret1, ret2, ret3;

  chip = gpiod_chip_open_by_name(chipname);
  if (!chip) {
    perror("The opening is failing...\n");
    goto end;
  }

  line1 = gpiod_chip_get_line(chip, line_num1);
  if (!line1) {
    perror("Get line 1 failed\n");
    goto close_chip;
  }

  line2 = gpiod_chip_get_line(chip, line_num2);
  if (!line2) {
    perror("Get line 2 failed\n");
    goto close_chip;
  }

  line3 = gpiod_chip_get_line(chip, line_num3);
  if (!line3) {
    perror("Get line 3 failed\n");
    goto close_chip;
  }
  printf("3 lines got\n");

  ret1 = gpiod_line_request_output(line1, CONSUMER, 0);
  if (ret1 < 0) {
    perror("Request line 1 as output failed\n");
    goto release_line;
  }

  ret2 = gpiod_line_request_output(line2, CONSUMER, 0);
  if (ret2 < 0) {
    perror("Request line 2 as output failed\n");
    goto release_line;
  }

  ret3 = gpiod_line_request_output(line3, CONSUMER, 0);
  if (ret3 < 0) {
    perror("Request line 3 as output failed\n");
    goto release_line;
  }
  printf("3 lines as output\n");

  gpiod_line_set_value(line1, 1);
  gpiod_line_set_value(line2, 1);
  gpiod_line_set_value(line3, 1);
  sleep(3);
  gpiod_line_set_value(line1, 0);
  gpiod_line_set_value(line2, 0);
  gpiod_line_set_value(line3, 0);
  sleep(3);

  for (val=0; val<100; val++) {
    putchar('.');  fflush(stdout);
    gpiod_line_set_value(line1, (val & 0x01) != 0);
    gpiod_line_set_value(line2, (val & 0x02) != 0);
    gpiod_line_set_value(line3, (val & 0x04) != 0);
    sleep(1);
  }
  printf("done\n");

release_line:
  gpiod_line_release(line3);
close_chip:
  gpiod_chip_close(chip);
end:
  return 0;
}
1 Like

Just got an email, @bbbpaul .

Thank you…

Seth

P.S. I bent some pins taking the a level shifter off the BeagleY-AI. Aw! Outside of that, I have not fulfilled the bending of the pins yet. Thank you for your logic behind some simple items of interest.

I appreciate your feedback and will attempt some ideas relative to your solution. I may copy and paste it but I am not sure just yet. And right about the "/dev/gpiochip2" line, i.e. as it is, it cannot work.

It needed to be a straight chipname outside of file location association.

Dang it…

update

Speaking of the file location used, libgpiod-example/libgpiod-led/main.c at master · starnight/libgpiod-example · GitHub , I attempted one GPIO with their source and exacerbated the issue into glory! Okay, enough from me…

@bbbpaul ,

I need to make sure the bits are toggling. For some reason, no go so far.

Maybe the board is goofed up or the Waveshare part is broken. I will attempt testing again.

Seth

Ut oh…so. i2c is in the way for now and I am not changing the DTS for now. I will stay patient or use the pins without the Hat Attached… Wait, that will not work either. Blah. DTS.

As a sanity check, first test without the hat attached and with no DTS or other changes. Simply use a default install, copy/paste mine or other known working code and check the pins with a multimeter/probe/scope etc.

1 Like

Yeppers.

Three lines done...
All lines are not output...
..........done...

Okay and everything compiles but not with success. The GPIOs are not being available when commanded. I am trying to see online now for the DTS for GPIO.

Seth

The board may be shotty. I will test that too.

Seth

P.S. the add-on board.

Okay…

So, gpioset works and each GPIO pin picked for usage all show data on the oscilloscope when I apply the below command:

gpioset $(gpiofind GPIO12)=1 and etc.

But, they do not make the Hat work with an 18v 1A PSU. Maybe I need something “beefier?”

Seth

P.S. I will try something else and see if it is the PSU making my life miserable.

I just checked the documentation for the hat, and it appars that the enable pin might actually be active high, not low as the pinout document posted earlier claims.
The chip enables are active low, but the circuit includes transistor inverters, Q1 & Q2.

So Seth - try pulling the enable pin high to step the motors instead of low.

1 Like

Nope…

So, I am going to test the “Hat” board. I tested the BeagleY-AI and it works. I received data on my o-scope. So, I know the GPIO pins are producing waveforms.

Seth

P.S. I also unplugged the barrel jack on the Hat and then plugged in a PSU on the header pins. Either/or should work but I wanted to make sure.

The enable pin from the BeagleY-AI when turned on does not produce on this Hat…

It may also be the darn driver on the first motor. I am only testing one motor as of now. Off to test that too but another night. I am beat for now.

One more thing to check - how are your mode setting switches set?
It’s possible that, if set to 32 microsteps, that the motor movement may be just too small to see. If the mode switches are set to 0,0,0 (full steps), then the degree of movement for each pulse on the step pin will be much more obvious.

1 Like