PWM Pin Error on Boot

I’m doing a project right now that involves using a micro servo. One is on port P8_13 and another on P9_14.

Everytime I boot the beaglebone it gives me - error: Error enabling PWM controls: Error: ENOENT, no such file or directory ‘/sys/devices/ocp.3/bs_pwm_test_P9_14.15/polarity’

When I check this file it shows a value of ‘1’ inside of it. Where the same file for P8_13 shows a zero. When I change the P9_14 polarity file to 0 the servo works as intended. I’m really confused why the polarity is being set to 1 every time I boot the beaglebone. This also happens if I move the servo to P9_16.

I did just upgrade from Debian 7.8 to 7.9 but I don’t see how that would change the GPIO behavior.

Hey everyone I’m still stuck as to why my beaglebone keeps changing the polarity to 1 on boot. I can go in and manually change it but it always resets after reboot. Should I maybe write a start up script to force the polarity to 0? I’d rather find the root cause rather than a hack but at this point anything that works is fine by me.

Thank you

Well, that depends on how skilled you are at modifying u-boot and the linux kernel?

In each case, modify the code that toggles the GPIO pin by printing text to the console when the GPIO you want is modified. You could always issue a kernel dump when that GPIO is modified, which will list the call sequence that causes the GPIO toggle. For the Kernel, I believe the code you want is in drivers/gpio/gpio-omap.c, but I haven’t looked at u-boot in a while, but it should be simple to find the equivalent code.

If you had a decent JTAG emulator, you could simply set a breakpoint on the GPIO toggle and then look at the call stack to see which routing is responsible.


Thanks for the reply John. I’m pretty new to modifying kernel modules and I haven’t worked with u-boot at all. I’m not sure at the moment when the GPIO is modified but I think it happens whenever the system resets, most likely on startup. Should I try a kernel dump right after I boot?


My guess is that u-boot isn’t modifying GPIO, so I would start with the kernel. I don’t know which kernel you are using, but Robert has some very cleaver scripts that make building the kernel quite simple.

I tend to use the second link for my kernels.

Once you have the kernel build, you can modify code in the KERNEL folder and then rebuild using:



One more thing, you may want to look at /driver/pinctrl/pinctrl-single.c as this is where the pinmux gets set.You could also use dynamic tracing to help find the responsible routine. Look in /Documentation/dynamic-debug-howto.txt. Probably a little bit of trial and error will be needed to narrow down this problem.