Pru Driver conflict with gpio

[Sergio Alejandro Salinas]

I hope you are doing well, I have been working in this problem some time now.

So, I am using LinuxCNC/Machinekit in a Beaglebone with a Probotix PBX-BB rev 5.2. I am trying to use three axis, with its dir and step signal.

At first I had the problem that the motor was moving in one direction only. This was solved by removing the pins used (812, 813, 814, 815) from the line from the .hal

loadrt hal_bb_gpio output_pins=816,818,819 input_pins=807,808,809,810,817

(so it was a pin conflict between both drivers, the gpio and the pru)

If I add the pins (812, 813, 814, 815) to the previous line, it moves in one direction, then if I edit the file to remove then, it moves as desired, but when rebooting, it stops working, and I need to do the previous steps (add and remove the pins).

I think the hal_bb_gpio is copying the configuration file to a directory the pru driver is not able to do alone, as consequence of how I have the configuration.

I attached my .hal .ini .bbio, and setup.h (until now, I have been working over the CRAMPS files).

What are your thoughts?

Thanks in advance

Sergio Salinas

[jgnoss]

You forgot to attach the .bbio file

and you didn't mention what files you are editing

There is no magic copying of files going on behind the scenes.

all files used should be located in the same directory and be referred

as ./filename or with absolute path

step 1

configure the Pins as input output ... whatever

that is done by config-pin utility that takes the .bbio file as input

step 2

loadrt hal_bb_gpio output_pins=XXX,XXX,XXX... input_pins=XXX,XXX,XXX...

does define the pins used in your config as input or output

Pins used direct by pru_generic (stepgen) shouldn't appear on that line

step 3

assign the pru pins to stepgen

setp hpg.stepgen.XX.steppin        XXX
setp hpg.stepgen.XX.dirpin           XXX

then it should work as expected

Axis Z in your .hal file uses

setp hpg.stepgen.02.steppin        816
# P8.29 PRU1.out9
setp hpg.stepgen.02.dirpin         818

but also configures those pins in bbio

loadrt hal_bb_gpio output_pins=816,818,819 input_pins=807,808,809,810,817

[Sergio Alejandro Salinas]

Thanks for your response jgnoss. For now I am ignoring the Z axis.

It is true I forgot to attach the .bbio file.

[jgnoss]

... and you didn't tell us what files at what location you are editing.

you should have all related files in one folder,

cd to that folder

edit them according to your configuration

supposed you didn't change the file names you then call

machinekit CRAMPS.ini

ju

[Sergio Alejandro Salinas]

Thanks jgnoss, it is true it is important.

~$ ls machinekit/configs/ARM.BeagleBone.CRAMPS/
3D.postgui.hal      autosave.halscope  CRAMPS.bbio  CRAMPS.ini                pru-stepper.var      README     setup.sh             ShuttleXpress.postgui.hal
3D.Temps.panel.xml  CRAMPS2.hal        CRAMPS.hal   CRAMPS.ShuttleXpress.ini  pru-stepper.var.bak  setup2.sh  ShuttleXpress.glade  tool.tbl

If I do ls, all the files (ini, hal, bbio, setup.sh) are in the same folder. The rest of the files are test I have been doing.

I think I have identified the problem. 

On the top of the CRAMPS.hal I have this lines:

# Launch the setup script to make sure hardware setup looks good
#loadusr -w /home/machinekit/machinekit/configs/ARM.BeagleBone.CRAMPS/setup.sh
loadusr -w ./setup.sh
loadusr -w config-pin -f ./CRAMPS.bbio

I have commented out the config-pin line, and I have the same result previously explained. I think my config-pin is not working properly for the kernel distribution I am using (4.19).

I found the correct OCPDIR and GPIODIR directories, but I couldn't figure out the SLOTS,  I tried with the /lib/firmware directory.

#!/bin/dash

# Some important directories for use later
OCPDIR=/sys/devices/platform/ocp/ocp*
GPIODIR=/sys/class/gpio
#SLOTS=/sys/devices/bone_capemgr.*/slots
SLOTS=/lib/firmware

If config-pin is not setting my setup, then hpg is not able to use the desired pins.

Does it make sense?

Does anyone using kernel 4.19?

Thanks in advance.

Finally my ootput to the shell script version.sh

machinekit@beaglebone:~$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[9599f8c47e18db5cdd36ee11355593ecdfe50979]
eeprom:[A335BNLTEIA05116BBBK3FEC]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[Machinekit Debian Image 2019-10-01]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gf15b99f0b6]:[location: dd MBR]
kernel:[4.19.72-bone-rt-r39]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.4.20190922.0-0rcnee0~stretch+20190922]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[machinekit : machinekit adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc admin spi tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[    1.138401] remoteproc remoteproc0: wkup_m3 is available
[    1.380413] remoteproc remoteproc0: powering up wkup_m3
[    1.380435] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[    1.382520] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[    0.760692] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[    0.771665] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

Sergio Salinas

[jgnoss]

>Does anyone using kernel 4.19?

Yes, I do.

I'm not sure if all that slots and bone_capemgr thing still applies or need to be touched.

I remember that I've had some issues finding that stuff running the 4.19 kernel.

currently I'm running

Linux beaglebone 4.19.82-bone-rt-r41 #1stretch PREEMPT RT Mon Dec 2 08:50:37 UTC 2019 armv7l GNU/Linux

I don't use HDMI, because I need the hardware encoder Pins so I run machinekit through ssh -X from another machine

in /boot/uEnv.txt I changed

disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1

because I don't need it

and make sure

enable_uboot_cape_universal=1

is set that way.

then I can use config-pin from the command line to check if it's doing what it's supposed to do

example:

$ /usr/bin/config-pin -q P9.23
P9_23 Mode: default Direction: in Value: 0

$ /usr/bin/config-pin P9.23 out
$ /usr/bin/config-pin -q P9.23
P9_23 Mode: gpio Direction: out Value: 0

or

$ /usr/bin/config-pin -q P8.11
P8_11 Mode: default Direction: in Value: 0
$ /usr/bin/config-pin P8.11 qep
$ /usr/bin/config-pin -q P8.11
P8_11 Mode: qep

So I know it works as expected

a .bbio file I used for some tests looks like

$ cat els_P_Mode.bbio

overlay cape-universal
overlay cape-bone-iio

P8_17 in #Estop In
P8_26 high #Estop out
P9_23 low #Machine Power

P9_15 high #Axis Enable, act. low
P9_17 low #dir
P9_18 low #step

P8_11 qep #Enc2_A
P8_12 qep #Enc2_B
P8_16 qep #Enc2_I

P9_27 qep #Enc0_A
P9_92 qep #Enc0_B
P9_91 qep #Enc0_I

and the corresponding hal file

$ cat els_P_Mode.hal

# load RT components

loadusr -w ./setup.sh
loadusr -w config-pin -f ./els_P_Mode.bbio

loadrt threads name1=fast period1=1000000
loadrt hal_bb_gpio input_pins=817 output_pins=826,915,923
loadrt hal_pru_generic prucode=/usr/lib/linuxcnc/rt-preempt/pru_generic.bin pru=1 halname=hpg num_stepgens=1  pru_period=2500
loadrt hal_arm335xQEP encoders=eQEP0

setp eQEP0.position-scale 13.33333

net enable => bb_gpio.p9.out-15
net enable => hpg.stepgen.00.enable
net pulse eQEP0.position => hpg.stepgen.00.position-cmd

setp hpg.stepgen.00.dirpin 917
setp hpg.stepgen.00.steppin 918
setp hpg.stepgen.00.stepinvert 0
setp hpg.stepgen.00.steplen 500
setp hpg.stepgen.00.stepspace 500
setp hpg.stepgen.00.dirsetup 500
setp hpg.stepgen.00.minvel 0.1
setp hpg.stepgen.00.maxvel 10000
setp hpg.stepgen.00.maxaccel 1500
setp hpg.stepgen.00.position-scale 4.44444

addf bb_gpio.read fast
addf eqep.update  fast
addf hpg.capture-position fast
addf bb_gpio.write fast
addf hpg.update fast

running it with

$ machinekit els_P_Mode.hal

the step motor shaft turns synchronous to the encoder shaft

that's everything it needs, hope you can pick something from that example

ju

[Sergio Alejandro Salinas]

This especific problem is now solved.

Thank you for your support jgnoss!

In fact, our files were pretty similar, but I noticed something trying your example

example:
$ /usr/bin/config-pin -q P9.23
P9_23 Mode: default Direction: in Value: 0
$ /usr/bin/config-pin P9.23 out
$ /usr/bin/config-pin -q P9.23
P9_23 Mode: gpio Direction: out Value: 0

or

$ /usr/bin/config-pin -q P8.11
P8_11 Mode: default Direction: in Value: 0
$ /usr/bin/config-pin P8.11 qep
$ /usr/bin/config-pin -q P8.11
P8_11 Mode: qep

my config-pin was not working properly, as I suspected. As you said that you changed nothing and using the same kernel (4.19), then I realized I may be using a different version of config-pin.

So, the one I was using and I modified (wrongly expecting to work) is this one:

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin

The one that did solve my problem is the one by Bjorn-J forked from RobertCNelson/bb.org-overlays:

https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin

Case closed. Now, to keep working until a new error appears.

Sergio Salinas