How to get started with BeagleBone Motor Cape

Hello silver2row,

thanks for your continuous will to support.

The PWM out of the BeagleBone Black is not a problem for me. Right now I’m familiar with the device tree overlays in general. But also in including/loading them via uEnv.txt or configure them myself via device tree source file (dts) first, “make” them, copy them to /lib/firmware and including/loading them in uEnv.txt.

It doesn’t matter if I did a pinmux via “config-pin” or via device tree overlay for P9.14 and then free wiring the cape, or a loading the complete device tree overlay (BBORG_MOTOR-00A0) and attach the cape fully on the BeagleBone Black.

In the first trials with pinmux only one pin and free wiring, everything looks quite good, beside the missing output at the motor terminal.
After the second trial with cape device tree overlay and attached cape, the BeagleBone Black won’t start anymore, if the VDD3V3 connection is pluged into the cape. Figured out with free wiring. It results seemingly in a shortcut, so the voltage drops to almost zero.

Q: Do you had been involved in the construction/engineering process of the cape?
Q: Can you assist me (e.g. how to measure at specific points) to justify a failure of the cape?

1 Like


I was not involved in the construction of this Cape nor was I part of the process.

  1. Wire the DC Motor to connector one in any way (only two ways).
  2. Attach a quick disconnect or however you are attaching your battery.
  3. Attach the battery.
  4. Plug in the Micro USB to USB 2.0 from the BBB to your dev. desktop.
  5. Use a power bank with 5v 2A to barrel jack and plug it in.
  6. Run the source.
  7. The motor should move.


P.S. The kicker is the Power to the barrel jack. The Cape will not work unless 5v is put to the barrel jack on the BBB. I am not sure if you understood this fact. It took me a while to understand it. I will keep attempting to help but it is three power connections, e.g. battery, Micro USB, and barrel jack for this MotorCape to function. Now, if you set up a .service file to run on boot, you can probably take away from real time programming and testing by subtracting the Micro USB cable to dev. desktop.

Oh! If you need some simple source, use the Adafruit_BBIO lib. that is available. It will be good for testing to see if everything is in working condition.

Oh and about that second question, yes. I can help. Plug in all three power supplies, attach your DMM to the connectors at PWR and GND and see if you read 12v or however many volts you are connecting.

You can also use the continuity test when supplying voltage to the BBB via barrel jack (I think). I will need to test this use case. I can. I will test it soon and reply.

Hello silver2row,

thanks for your answer. I already wrote :

the BeagleBone Black is supplied with a 2 A power supply via barrel jack and the cape is supplied with a labratory power supply with currently 24 V and 3 A via the power terminal. The DC motor was previously driven with it from 2 V and 250 mA till 26 V and 1 A.

For sure the power supply is done right. Either to the cape or to the board itself. From Ground up / my approach from beginning was as follows: board → cape attached to board (first attemps via free wiring) → power supply 24 V DV 3 A attached to the cape → barrel jack with 5 V DC attached to board → board booted → PWM configuration → but no output voltage on the cape and therefore no motor running.

Just to make things clear. I know about the issue to properly power the board (some say via power jack first, boot and then plug in usb) and the cape (ability to supply enough current). Isn’t
But from my understanding, a voltage should be measured at the motor terminal of the capes, even if no motor is connected there; or not?

It is currently too early to use / try out any libraries. First of all, the motor at the cape should run with PWM. For now on I can configure my PWM via linux shell commands. In the future I can dice into others ways.

Probably the cape is defect and I need a new one. The pins on the capes ic were correct at my first trials.

Q: At what frequency and Durty cycle did you run your motor. Does this play a role for DC motors or in which range should the values lie? (I have already written that I had already tried all possible values without result).


I am not sure, I guess.

Have you set up your dts and BeagleBoard-DeviceTrees/BBORG_MOTOR-00A2.dts at v4.19.x-ti-overlays · beagleboard/BeagleBoard-DeviceTrees · GitHub .

For a bit, there was something called Bone-Buses, too. So, setting the GPIO pin to HIGH/LOW may not work unless the dts is done correctly.


P.S. Let me go and check for the Bone-Buses idea for the MotorCape. Okay, I see an issue. If you are not on 4.19.x, the Cape dts is not available by You will have to write your own for kernels older than 4.19.x. If you are on 4.19.x, you can use their dts.

Hello silver2row,

as I already wrote:

For completenes I use the official released distribution Debian Buster 10.3 (bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz) and Kernel 4.19 (linux-image-4.19.165-bone-rt-r59_1buster_armhf.deb).

Therefore I can use the preinstalled “BBORG_MOTOR-00A2.dtbo” file or compile the “BBORG_MOTOR-00A2.dts” file from github and copy it to /lib/firmware and then loading it via uEnv.txt. Or I can do it as decribed with free wiring the cape and use only one PWM:

  1. Pin configuration as PWM:
    non permanent: config-pin P9.14 pwm
    or permanent by loading the device tree overlay “BB-PWM1-00A0.dtbo” (old syntax) or compiling the device tree source “BONE-PWM1.dts” (slight changes needed: &bone_pwmss_1 → &epwmss1, &bone_pwm_1 → &ehrpwm1) and loading the resulting device tree overlay “BONE-PWM1-dtbo” in /boot/uEnv.txt

The PWM and even the GPIO is not a problem for me (anymore :wink:)

I wired the GND, VDD.3V3, SYS.5V, one PWM and one GPIO pin. Unsuccessfully for the output of the cape.

My only problem was (really) no output at the motor terminals; in the first place. Then with cape attached to the board, 3.3 V rail dropped, so no boot for the board is possible anymore. Now also the free wiring fails if 3.3 V connected.

My current conclusion is, that there is a failure in the cape, but I can’t figure it out (where and especially why). Can you find any fault in my steps of investigation?

Therefore I have buy and try another one… Sadly but still hopeful…


The image you are using is dated. Try the Bullseye image w/ the 4.19.x kernel instead.


P.S. This could be an issue. I no longer use the older Buster images. There are even newer Buster images, I think. Did you try another image yet?

Hello silver2row,

and thanks for your sustained will to help!

I already know about that there are newer builds around there, and thought about trying a newwer build or version in general. I downloaded the 10.8, 10.12 and 11.3, but not tested them yet. But in the end they are not officially released, so functionality is probably worse than the recommended 10.3 from

I know about the snapshot site and the balena Etcher. But thanks.

So lets go on logically. What do you think will change? The cape needs PWM (range of period and duty_cycle still unclear; but 500 Hz for right now), power supply (sufficient power supply capacity) and nothing more. If I want to change direction GPIO; already tried. Every requirement was fullfilled; isn’t it or still something missing?

What makes you think that it would work with a new version or what would be different then?
It would be more like groping in the dark.

From my point of view there is no imagination on how to crash the cape, so it would not output at the motor terminals and later do a shortcut for the 3.3 V rail…

Q: Perhaps the capes motor termials need a specific load and my motor is not the right one? Or shouldn’t I still see a voltage at about 2/3 of supply voltage at the motor terminals at all without a motor connected, for any reasons? (I tested w/ and w/o motor connected; but no output)

If all the discurs leads to a dead end, I have to dive into how double H-bridges are working. uuuaarrrggg (not willing to do so ;-))

Have a nice day

Hello silver2row,

the current exceeds 1,5 A during testing with only free wiring VDD.3V3 and GND. It seems to be an defect on my board.
The 5 V rails are OK.

Can you probably confirm/check that with your cape?

From the schematic of the cape, there shouldn’t be such a current consumption. Possible issues could be:
-any of the capacitors C2, C3, C4, C5 has a defect and does a shortcut from VCC to GND
-the EEPROM U1 has a defect and shortcuts VCC and GND

  • resisitor R8 has adefect and shortcuts VCC and GND

From a soldering point of view everything looks OK. Also the components on the cape looks OK. No optical issue can be detected.


I am not sure what to say now. I do have one here. I can test it again. I will update you at some point. I have a few other ideas on building Linux systems that I am currently trying to configure.


P.S. After a couple more tries and builds, I will attach the MotorCape and try my ole repo.

Hello @smanko ,

Okay…so. I am installing a new image now. I will update you in about an hour.

I will install some source, the Cape, and the correct connections and return service.


P.S. If I am successful or not, I will still reply.

Hello @smanko ,

So, it seems I cannot get past a particular point in managing my source:

OSError: could not access a necessary file


P.S. Until later, this is as far as I can get. Oh. Look to udev rules in /etc/udev/rules.d/. You may have to research setting up udev rules for PWM Access. I will upload a video soon. I cannot get GPIO to work just yet for whatever reason.

Bear w/ me.

Here is a short on the MotorCape and PWM. Still…I cannot handle the GPIO for the Cape so far.

Hello silver2row,

I think you still don’t get me in some points. I don’t have problems wth PWM. PWM works at P9.14 and P9.16 on my board and should drive motor 1 and 2.

Perhaps my steps can help you getting a working test cape: :wink:

  • Flashing the official image “AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher” from - latest-images on an µSD-Card
  • Put the µSD-Card in the board and power it via barrel jack
  • After all lights went off after about 10 min., pull out the µSD-Card and the barrel jack
  • Put in the mini USB cable (and board will boot)
  • Load the BBORG_MOTOR-00A2.dtbo file in uEnv.txt and power off
  • Attach the motor cape to the board
  • Connect the motor and the power supply to the cape
  • Power up the board with barrel jack and plug in USB cable afterwards
  • Check the loaded overlay via “sudo /opt/scripts/tools/”
  • Check the pin configuration via “sudo /opt/scripts/device/bone/” (P9.14 and P9.15 should be assigned to pwm1 bus)
  • Configure the pin via “echo 2000000 > /sys/class/pwm/pwmchip4/pwm0/period” and “echo 1000000 > /sys/class/pwm/pwmchip4/pwm0/duty_cycle”
  • Aktivate the pwm on pin via echo 1 > /sys/class/pwm/pwmchip4/pwm0/enable

Q: Is the motor working?

Thanks in advance for replicate my scenario to get this cape to work. Any steps (special code or distro to run the motor) beyond this functionallity will be afterwards for me.

Hello…you need GPIO and PWM to handle each separate motor.


P.S. So, P9_16 (PWM) and GPIO P8_18 (GPIO) handle motor One and etc. No, the motor does not work yet.

I will keep attempting it until completion.

Hello…in which way I will need the GPIO? I thought it’s needed for direction inrversion if HIGH.

1 Like


Direction. If you want to handle direction, GPIO is what to use.

If you are just making a motor go in one direction, GPIO. If you have two direction motors, GPIO.


On = PWM, Off = PWM. Right? I mean it. Am I right? To tell you the truth, I do not know why it is not working right now. P8_18 is listed as gpio. My PWM light, the LED, lights on and off. I am confounded here. Hello Again…

I think I am just using the wrong board. The BBGG has specific parts used to handle onboard peripherals. I will try another board.

@smanko ,

It works!


P.S. The BBGG is using some specific pins that are needed to handle the MotorCape. Wait for video!

Here is 5* speed on it working:

Hello @smanko ,

did you get up and runnin’ yet?


Hello silver2row,

my new Motor Cape has arrived and being tested.
Good news: no voltage drop, so board can boot.
Bad News: No voltage on the outputs and no motor movement.

My overlay configuration:
uEnv.txt: uboot_overlay_addr4=/lib/firmware/BBORG_MOTOR-00A2.dtbo

My hardware configuration 1:
Board P9.1 <-> Motor Cape P9.1 (DGND)
Board P9.2 <-> Motor Cape P9.2 (3.3V)
Board P9.14 <-> Motor Cape P9.14 (PWM)
Board P9.2/P9.3 <-> Motor Cape P8.18 (direction) (optionally)

My hardware configuration 2:
Motor Cape attached to the Board

Sell commands:
config-pin P9.14 pwm (pin mux as PWM)
echo 2000000 > /sys/class/pwm/pwmchip4/pwm0/period (pin configuration with 500 Hz)
echo 1000000 > /sys/class/pwm/pwmchip4/pwm0/duty_cycle (pin configuration for half voltage level ~1.6 V)
echo 1 > /sys/class/pwm/pwmchip4/pwm0/enable (enabling pin)

With both hardware configurations, the voltages and PWM signal looks and measures good so far. But no output. There must be something missing.

Did you tried same way with your Board and Motor Cape in the meanwhile?
(Only hardware seems to be relevant. Software for putting out the pwm shouldn’t be a difference/topic.)

Can anybody help me getting this Motor Cape working???

Hello @smanko ,

Maybe someone else will help you more than I can right now. I have tried everything to relay what I have learned about the MotorCape.

If you have evidence that it does not work at all, I would have to say, “No, it works.” I got my Cape, this MotorCape, up and runnin’ just a week ago.

Did you try any udev rules in /etc/udev/rules.d/?


P.S. Maybe the PWM and GPIO lines do not understand how to be used outside of the root account.

For instance:

  1. What does ls -l /dev/gpio* say?
  2. What does ls -l /dev/pwm* say?
  3. What is the output of those two commands? This may help the both of us understand more about how we can help one another.

Hello silver2row,

perhaps we can figure out the differences of our both configurations/installations?!
Nice if the Motor Cape works for you. I would like so too!

A: No, I didn’t make any udev rules in /etc/udev/rules.d/ ?

A: The ls -l /dev/gpio* say:

crw-rw---- 1 root gpio 254, 0 Apr 7 17:17 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Apr 7 17:17 /dev/gpiochip1
crw-rw---- 1 root gpio 254, 2 Apr 7 17:17 /dev/gpiochip2
crw-rw---- 1 root gpio 254, 3 Apr 7 17:17 /dev/gpiochip3

A: The ls -l /dev/pwm* say:

No such file or directory

But loading the device tree overlay “BBORG_MOTOR-00A2.dtbo” via uEnv.txt, the information for the pins via sudo /opt/scripts/device/bone/ seems OK:

P9.14 18 U14 fast down 6 pwm 1 out A pwm@48302200 (pinmux-bborg-proto-ehrpwm1-pins)

For testing purposes the frequency is currently 500 Hz and 1,6 V DC. (Also tested unsuccessfully with other frequencies). Perhaps the h bridges needs a specific frequency and voltage? I can’t imagine but I don’t know.

The PWM and GPIO line shouldn’t be a problem in my opinion as already described. It seems that you slightly jumped over my point and statements about this. Why do you think it makes any difference? Hopefully we can make things clear to get this cape running together. You are the only person who can help me because for you it’s running and you probably can do some test to reverse engineer the critical steps!? Please keep on with me on that issue!

Q: Can you try your same application if cape is not attached to the board directly but laying next to each other and free wiring the necessary pins?
(i would suggest: P9.1 (DGND), P9.2 (3.3V), P9.14 (PWM), P8.18 (direction) (optionally))

If that installation will still work for you, we could jump to the next test and have a look at the pwm (frequency, voltage)