PWM Initialization Produces RuntimeError: Problem with cape manager

[sohotaling]

I'm using a BeagleBone Black to control a stepper motor, three limit switches, a relay, and a touchscreen (4D Systems 70T, see ). Although the LCD touchscreen is a cape, plugging into all 46 pins, I've used an Adafruit proto-cape, a pair of stacking headers, and some rudimentary soldering (see images below) to get the IO I need from the BBB while allowing the LCD cape's signals to pass unhindered. Obviously, I took care not to use any pins required by the LCD cape.

When the LCD cape is not plugged into the BBB, Adafruit_BBIO.PWM's features work - my stepper motor behaves as expected. When the LCD cape is plugged into the BBB, regardless of whether or not the passthru proto-cape is present, running a line like PWM.start('P8_13', 50, 1000, 0) produces RuntimeError: Problem with the cape manager. This seems only to occur with PWM - GPIO works fine - but occurs with all PWM pins not used by the LCD touchscreen (I've avoided testing pins used by the touchscreen while it's plugged in).

Checking in on the loaded device tree overlays with cat /sys/devices/platform/bone_capemgr/slots, we see four empty slots when the touchscreen is absent, and the following output when just the touchscreen is present:
0: P---L- 0 4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LCD7-01
1: PF---- -1
2: PF---- -1
3: PF---- -1

My understanding is that P8_13 is driven by EHRPWM2. I attempted to ensure that this was activated by running echo BB-PWM2 > /sys/devices/platform/bone_capemgr/slots, which returned no errors.
cat /sys/devices/platform/bone_capemgr/slots now yields the output:
0: P---L- 0 4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LCD7-01
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 1 Override Board Name,00A0,Override Manuf,BB-PWM2,
but attempting the above line yields the same result: RuntimeError: Problem with the cape manager.

What's going on, and how can I fix this? Is the device tree overlay loaded from the cape's EEPROM interfering with Adafruit_BBIO's device tree bindings?

Thanks for your help.

System details:

Platform: BeagleBone Black, Rev. C
OS: Debian GNU/Linux 8.6 (jessie) on SD card
Kernel: 4.4.9-ti-r25
Python Version: 2.7.9
Adafruit_BBIO version: 0.0.30
Adafruit_BBIO.PWM version: 0.0.20

[pdp7]

I'm wondering where the source for device tree overlay comes for the 4D LCD cape that is being loaded:

0: P---L- 0 4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LCD7-01

I'd like to determine if this is it:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD7-01-00A3.dts

Could you go through the install steps for bb-overlay?
https://github.com/beagleboard/bb.org-overlays

[sohotaling]

I already had Robert C Nelson's bb.org-overlays installed. Reinstalled, rebooted. Tested PWM with and without LCD touchscreen, tested with and without BB-PWM2 echoed to /sys/devices/platform/bone_capemgr/slots. Same results as before.

[xiiihyou13]

I'm having the exact same problem. I have no cape attached (bare beaglebone black), only PWM gives out this error.

[pdp7]

@sohotaling @xiiihyou13:
I think it would be useful to learn more about what happens when attempting to execute PWM.start(). @MatthewWest had used this method successfully to debug Adafruit_BBIO issues in the past.

Run the following commands, and paste the output (trace.txt) into a gist for me to look at:

# Install strace somehow (not sure what the package management situation is on kamikaze)
# on Debian it'd be
sudo apt-get install strace
sudo strace -o trace.txt python3  # Or python

from Adafruit_BBIO import PWM
PWM.start('P8_13', 50, 1000, 0)
# press Ctrl-D

Then upload the contents of trace.txt into gist.

Per @MatthewWest:

If you're not familiar with it, strace is a fantastic tool for seeing what system commands a program makes (file opening, writing, etc.). Hopefully this will let us see what errors it is hitting.

[xiiihyou13]

@pdp7 I'm not quite familiar with github. is this correct? https://gist.github.com/xiiihyou13/e3caa6f5921bc633167261940eda8fe4#file-trace-txt

[sohotaling]

@pdp7 @MatthewWest I've used strace and the first two lines of Python commands above, as well as defunkt's handy gist command to generate then upload some txt files. They can be found in my gist repo. Both tests were run with my /sys/devices/platform/bone_capemgr/slots empty, and no capes plugged into the bone.

The first problem to jump out at me in each test is that Python is unable to find a series of files:
(from SD-PWM-slots_empty-trace):
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
stat64("/usr/local/sbin/python", 0xbeeaf940) = -1 ENOENT (No such file or directory) stat64("/usr/local/bin/python", 0xbeeaf940) = -1 ENOENT (No such file or directory) stat64("/usr/sbin/python", 0xbeeaf940) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/lib/python2.7/os.py", 0xbeeaf8b0) = -1 ENOENT (No such file or directory) stat64("/usr/bin/lib/python2.7/os.pyc", 0xbeeaf8b0) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.7/os.py", {st_mode=S_IFREG|0644, st_size=25914, ...}) = 0 stat64("/usr/bin/pybuilddir.txt", 0xbeeaf8c0) = -1 ENOENT (No such file or directory) stat64("/usr/bin/lib/python2.7/lib-dynload", 0xbeeaf8c0) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.7/lib-dynload", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/lib/python2.7/site", 0xbeeb07f8) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/site.arm-linux-gnueabihf.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/site.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/sitemodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

The Bone tries multiple times to access the above files - checking the directories manually confirms their absence. Does this mean there's a problem with my Python installation? Is there a method for testing and/or repairing it?

Cheers,

Sam

[pdp7]

@sohotaling Those ENOENT errors are normal. However, I should have asked you to run strace with the option to follow child processes.

Please run this:

sudo strace -f -o trace.txt python

Then enter this:

from Adafruit_BBIO import PWM
PWM.start('P8_13', 50, 1000, 0)

[pdp7]

@xiiihyou13

Could you please specify which image and kernel your BeagleBone is running?

cat /etc/dogtag
cat /etc/debian_version
uname -a

I've recently published Adafruit_BBIO v1.0.0 to PyPi. Pleas update to make sure you are using it:

sudo pip install --upgrade Adafruit_BBIO

Finally, I should have asked you to run strace with the option to follow child processes.

Please run this:

sudo strace -f -o trace.txt python

Then enter this:

from Adafruit_BBIO import PWM
PWM.start('P8_13', 50, 1000, 0)

[sohotaling]

@pdp7 Double-checked to ensure that Adafruit_BBIO was version 1.0.0 and not 0.0.30. Re-ran
strace -f -o xxx.txt python
from Adafruit_BBIO import PWM
PWM.start('P8_13', 50, 1000, 0)

Results found in my gist.

[MatthewWest]

Relevant part of the gist starts at line 2122.

[MatthewWest]

Just kidding, all the lines start with the same number. The gettimeofday command is the beginning of the important section.

[SforSwordfish]

I am having the same problem on my beagle bone green wireless. What I am currently running:

BeagleBoard.org Debian Image 2016-09-18
8.6
Linux beaglebone 4.4.21-ti-r45 #1 SMP Fri Sep 16 23:35:29 UTC 2016 armv7l GNU/Linux

I will experience the problem. However, I can connect to my BB through the access point via WIFI. The lights on the board will go from "dancing" in unison to D4 being lit and D2 blinking in a heartbeat fashion. Then I can run the exact same program using PWM and it will be completely fine with no errors.

The problem appears that the device tree overlay is not added to the cape manager but after accessing the BB thru the access point it becomes added.

I know this because using cat /sys/devices/platform/bone_capemgr/slots proves it.

I'm not sure what the actual problem is but I just use this as a work around.

[pdp7]

@MatthewWest I see several instances of gettimeofday in that gist. Was there a particular one that you are referring to?

[sohotaling]

@pdp7 @MatthewWest Where do we stand on this? I've read these error messages a couple times now, and I'm still unsure of the root of the problem, or how to fix it. How do we proceed from here?

[MatthewWest]

@pdp7 Sorry, I've been a bit busy with schoolwork. The relevant section of the gist starts here.

I believe that I've figured out the problem — the PWM implementation of this library for BeagleBone 4.1+ requires that a universal cape be present. Most of the time, this works really well—universal capes allow all the functions to be used without explicitly enabling them at boot, just requiring pin-muxing. The downside is that if a hardware cape uses pins which conflict with universal cape pins, the universal cape won't be loaded, and it can't be used to enable functionality.

Unfortunately, this isn't a simple fix. Here's a comment from the author of universal overlays on their pros and cons - one of the cons is that they are not as flexible. The fix would involve 1 of 2 things. One option would be to make a custom version of the universal overlay, with the offending pins removed. The other option would be to make our own overlays for each pin, and load / unload them as needed from our library.

I don't have time to work on this at the moment, since it's the middle of an academic term. Hopefully I've put some useful information here.

[pdp7]

Thanks for your insights, @MatthewWest!

[sohotaling]

As Drew says, thanks, @MatthewWest. I'll try loading some universal capes with and without the touchscreen, and may need to dump the touchscreen altogether in favor of standard HDMI output and a USB hub for input. Really appreciate the help from both of yall @pdp7

[pdp7]

@sohotaling are you still experiencing this issue?

[pdp7]

@sohotaling can this issue be closed?

[sohotaling]

@pdp7 Sorry for the slow response - I too have been able to dedicate little time to sorting my BBB out. Yes, I'm still experiencing this issue - I'm going to start testing this on earlier versions of Debian Linux and see what happens. Kind of stuck :/

[pdp7]

@sohotaling Thanks, yeah, that would be useful if you could contrast results using an earlier version

[pdp7]

@sohotaling any update this issue? were you able to make any progress? thanks

[pdp7]

Please re-open if issue still exists

[elfgoh]

I am experiencing this issue still. Would like to request this issue to be reopened please. I am assuming only an admin can do this.

Or should I file a new issue?

Update: saw a note that I should post in the adafruit forum. Will proceed to do so

[pdp7]

@elfgoh please open a new issue and reference this issue in the description.

I monitor both the BeagleBone forum on forums.adafruit.com and this GitHub repo. For an issue specific to the Adafruit_BBIO library, I do prefer creating a GitHub issue in this repo as it easier to keep track of than an Adafruit forum post. Thanks.