Getting EQEP2 to work on the PocketBeagle

Hi,

I’m trying to hook up a PocketBeagle to a pololu Zumo chassis. After getting QEP0 to function I’m now struggling to get QEP2 going. Once I add the U-Boot overlay for it the PocketBeagle does not boot anymore. I’m guessing that I’m missing something in the device tree stuff for the PocketBeagle, and by now could use a nudge in the right direction :slight_smile:

I verified that the hardware is ok by hooking things up to my old beaglebone white and the EQEP there reads things correctly.

I’m using bone-debian-9.2-iot-armhf-2017-10-10-4gb.img with kernel 4.4.91-ti-r133 and the latest package updates.

In my boot/uEnv.txt I have made the following changes:

enable_uboot_overlays=1
uboot_overlay_addr0=/lib/firmware/pb_eqep0.dtbo
#uboot_overlay_addr1=/lib/firmware/pb_eqep2.dtbo
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
enable_uboot_cape_universal=1

For the pb_eqep0.dts I used the latest https://github.com/beagleboard/bb.org-overlays.git as a basis. With this overlay the eqep sysfs entries appear and the position can be read like on my BeagleBone.

Once I uncomment the line with pb_eqep2.dtbo in the uEnv.txt the boot fails. I have collected the dts files and the u-boot output in this gist:

https://gist.github.com/rklaren/09cf8a0a031a857421ae1501ca6d59dc

I have tried:

  • just enabling the EQEP’s by using config-pin but then the sysfs entries do not appear (or maybe something else needs to be disabled in the device-tree to make that work).
  • Merging the two dts/dtbo’s but that leads to the same U-Boot output.

Any pointers would be appreciated.

Cheers,

Ric

Using config-pin to enable the eqep's by default is all you should
need, no extra overlay..

Which pin's are you using, and please share the output of this script:

sudo /opt/scripts/tools/version.sh

Regards,

Hi,

Thank you for the help.

I’m trying to use both QEP0 and QEP2. If I use config-pin like the following the QEP entries in the sysfs do not appear:

config-pin -a P2_34 qep
config-pin -a P1_31 qep

config-pin -a P2_24 qep
config-pin -a P2_33 qep

ls /sys/devices/platform/ocp/*.epwmss/
/sys/devices/platform/ocp/48300000.epwmss/:
48300200.pwm driver driver_override modalias of_node power subsystem uevent

/sys/devices/platform/ocp/48302000.epwmss/:
48302200.pwm driver driver_override modalias of_node power subsystem uevent

/sys/devices/platform/ocp/48304000.epwmss/:
48304200.pwm driver driver_override modalias of_node power subsystem uevent

The output of /opt/scripts/tools/version.sh is in this gist: https://gist.github.com/rklaren/e2cf4bee8b708226843c51572a74a93d

This is with a very plain /boot/uEnv.txt. Note the tieqep kernel module is already loaded before invoking config-pin.

Aside note: In this setup /proc/cmdline will not contain bone_capemgr.uboot_capemgr_enabled=1 either. Which seems to be expected by Adafruit-BBIO which results in ‘RuntimeError: Problem with the cape manager’ messages (for instance when attempting to use pwm).

If I enable the overlay for QEP0 I get:

ls /sys/devices/platform/ocp/*epwmss/
/sys/devices/platform/ocp/48300000.epwmss/:
48300180.eqep 48300200.pwm driver driver_override modalias of_node power subsystem uevent

/sys/devices/platform/ocp/48302000.epwmss/:
48302200.pwm driver driver_override modalias of_node power subsystem uevent

/sys/devices/platform/ocp/48304000.epwmss/:
48304200.pwm driver driver_override modalias of_node power subsystem uevent

And EQEP0 works. But as mentioned before I have trouble getting QEP2 configured. Will config-pin become the standard way of doing things? In stead of u-boot overlays?

Aside note: Also /prod/cmdline will now contain bone_capemgr.uboot_capemgr_enabled=1 and the Adafruit-BBIO library starts to work (for PWM and EQEP0). I suspect the adafruit library needs an update/tweak.

Any thoughts?

Cheers,

Ric

Hi,

Update: It seems I was not fully paying attention when running config-pin (I ran it from a script) I actually get an error when attempting to configure P2_24:

config-pin -a P2_24 qep
dash: echo: I/O error
Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P2_24_pinmux/state

config-pin -q P2_24 qep
P2_24 Mode: default Direction: pin_not_exported Value: pin_not_exported

dmesg shows this error:

[ 68.234357] bone-pinmux-helper ocp:P2_24_pinmux: Failed to find state qep

Cheers,

Ric

Hi,

Answering myself: upgrading to bone-debian-9.3-iot-armhf-2018-01-28-4gb.img, with kernel 4.9.78-ti-r94 improves the situation.

The pins can be configured with config-pin but sysfs entries for the eqep do not appear, I assume that is a bug?

The overlays I created earlier now work though, so pins are configured correctly at bootup and the sysfs entries appear.

https://gist.github.com/rklaren/09cf8a0a031a857421ae1501ca6d59dc

Cheers,

Ric

This has been very helpful but I have a problem - the position counter only decrements in my python code. The signals from my AMT103-V capacitive encoder from CUI, Inc, look good on my oscilloscope but unplugging P2_33 doesn’t change a thing (position continues to decrement) while unplugging P2_24 stops eqep2 from counting. Reversing the two external signal wires produces the same output so this is consistent with P2_24 being the only active pin.

###after bootup use config-pin:
config-pin -a p2_24 qep
config-pin -a p2_33 qep

###Code:
from Adafruit_BBIO.Encoder import RotaryEncoder, eQEP2
import time
myEncoder = RotaryEncoder(eQEP2)
while (1):
cur_position = myEncoder.position
print cur_position
time.sleep(1)

###Output:
-1
-120
-239
-364
-486

output of sudo /opt/scripts/tools/version.sh (note I also tried to enable eQEP0 as a test of the A/B signals but P1_31 in error)

git:/opt/scripts/:[e307a944e0be0610ff5296e0abe4ad31a6e70daa]
eeprom:[A335PBGL00A21736GPB20285]
model:[TI_AM335x_PocketBeagle]
dogtag:[BeagleBoard.org Debian Image 2018-03-05]
bootloader:[microSD]:[/dev/mmcblk0]:[U-Boot 2018.01-00002-ge9ff418fb8]:[location: dd MBR]
kernel:[4.9.82-ti-r102]
nodejs:[v6.13.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/bone_eqep0-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr2=/lib/firmware/bone_eqep2-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20180305.0-0rcnee0~stretch+20180305]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 1.424230] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[ 19.138778] pinctrl-single 44e10800.pinmux: pin PIN104 already requested by ocp:P1_31_pinmux; cannot claim for 48300180.eqep
[ 19.205338] pinctrl-single 44e10800.pinmux: pin-104 (48300180.eqep) status -22
[ 19.257765] pinctrl-single 44e10800.pinmux: could not request pin 104 (PIN104) from group pinctrl_eqep0_pins on device pinctrl-single
dmesg | grep gpio-of-helper
[ 1.432715] gpio-of-helper ocp:cape-universal: ready
END

###/boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.9.82-ti-r102
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1

Ric and Robert,

THANK YOU! It was a slog getting Ric’s overlays compiled (for an old guy) but both encoder channels work well and simultaneously on the PocketBeagle. Config-pin doesn’t work as the pinmux files for p1_31, p2_34, p2_24, and p2_33 aren’t there – I suspect there is something in the overlays which also must be for the case when using the provided bone_eqep0-00A0.dtbo and bone-eqep2-00A0.dtbo files. So, I’ve still got a lot to learn but this should allow me to point a 175 year old telescope at any object in the sky – at least that is the plan.

Thanks again!
Mark

#################### Original problem posting