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.
Seth
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
Seth
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: 
- Flashing the official image “AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher” from BeagleBoard.org - 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/version.sh”
- Check the pin configuration via “sudo /opt/scripts/device/bone/show-pins.pl” (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.
Seth
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
Okay,
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.
Seth
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!
Seth
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 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)
Summary:
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/?
Seth
P.S. Maybe the PWM and GPIO lines do not understand how to be used outside of the root account.
For instance:
- What does
ls -l /dev/gpio*say? - What does
ls -l /dev/pwm*say? - 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/show-pins.pl 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)
Hello @smanko ,
I do not know what else I can do to help but I can only try.
…
For one, I say this…
- Try a udev rule in
/etc/udev/rules.d/for PWM where you can use the/dev/pwmoutside of root.
Secondly,
- Once that is done, try your source again.
Seth
P.S. I think beagleboard.org has some device-trees or some type of customizations full of udev rules to handle being a user outside of root for using your peripherals on the BBB. Oh and after updating the udev rule, try to reboot the BBB.
Hello silver2row,
you could help by measuring your PWM, so we can check that against my PWM
Is there any chance you can do the measuring and step by step evaluating the issue with me?
A1: I still do not understand what you are getting at, with the udev rules/source and software in specific and in general. Perhaps you can please describe what it is supposed to do? Do you really think it makes any difference how the software creates the PWM signal at the pin?
It pretty seems to be an hardware issue, in something is missing or different to your signals.
Again: I don’t have problems with producing a PWM signal out of the board. The PWM is physically present measured via multimeter!
A2: What do you mean with source?
Maybe I’m completely lost because I’m a beginner, but it would be very helpful if you could argue about the steps you whant me to do. In my opinion we do something in software on the board, to get a specific hardware reaction. Isn’t it?
Do you see any faults in my hardware (PWM signal with frequency and duty cycle; 3.3V and GND instead of GPIO); and power supply to the cape?
Again, can you do this test?
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)
Hello,
@smanko , I am not going to measure everything just yet. Did you try w/out the .dtbo file in /boot/uEnv.txt and a udev rule yet?
Source is software or another name for it.
A1: Write up some software to handle PWM and GPIO on your BBB when the MotorCape is attached.
A2: Source or software or code.
Do you have any code yet to handle the PWM and GPIO peripherals on the BBB which control the Direction and On/Off states of the MotorCape from L298 drivers?
Seth
P.S. There are some PWM peripheral udev rules you might need. customizations/etc/udev/rules.d at master · beagleboard/customizations · GitHub .
Hello silver2row,
I think we sometimes talk past each other…
A: Yes, I’ve tried w/o the dtbo file. It’s only for pinmux during boot and it can also be done after boot with the command config-pin P9.14 pwm. No, I’ve not tried any udev rule yet. But if you think it makes any difference i have no idea about it and have to dive into this topic first.
A1: What do you exactly mean by “Write software to handle PWM and GPIO?” Isn’t it enough in the first place to generate a static PWM and use 3.3V and DGND as a substitute for GPIO? On the other hand I still wrote a script that do all this after bootup automatically.
You are not going to measure your cape (pins, PWM)?!? 
First I want to get a motor spinning with static PWM and velocity. After that I can think of how to modify this PWM during runtime. (I’ll use CODESYS Runtime for BeagleBone SL to control the board). But if I can’t get the motor spinning it doesn’t make sense to code any software that change the velocity of it. Can you see that arguement?
And yes, I already tred with GPIO for direction instead of only 3.3V and DGND, w/o success.
Control of direction is done via the M1-M4.HIGH pins. Control of velocity is done via the M1-M4.PWM pins. Control of On/Off states is done via ??? 
There is an On/Off Control? Where can I find it and how can I control it? Perhaps it is what is still missing.
BTW: I don’t have any issues with any other of the capes (COMMS Cape, Load Cape, Relay Cape) with free wiring and attached.
I really want to get this cape working, but I need the help from a guy like you. And it should be done systematically. What is needed in general. What is on your side and what is different / missing on my side. I would be so grateful if you could do that with me.
And it would realy nice to have a talk about the points to resolve my issue. E.g. why I should write a specific software instead of configuring the PWM with the forementioned commands? Why not using 3.3V and DGND instead of GPIO? Can voltage being measured w/o a motor connected to the output screw terminal? And so on…
Or perhaps you can tell me who or where else I can ask about this motor cape?
I appreciate your will and time!
1 Like
Hello,
I am sure this is frustrating. I was frustrated at first too. I could not understand why the L298 on different board I had only used GPIO when these can be controlled and have to be controlled by both PWM and GPIO.
So, control it, and I know this seems silly to say, with a GPIO pin when the LED is on. So, you have your PWM peripheral from the BBB notifying the Cape (MotorCape) about everything PWM but then, you have to have the matching GPIO pin number that goes w/ the PWM pin for each, say, DC Motor.
I had a hard time grasping it at first. And then…what blew me away was this idea.
I had to have a barrel jack DC supply to the BBB w/ the Cape attached, this MotorCape, so that it would work.
I hope I am making sense. I am trying.
So, let me say this:
- Here are some ideas from what I gathered and there was a nice person on the IRC channel that seemed to know way more than I. This person helped me.
motor1 = Motor(dir_pin="P8_18", pwm_pin="P9_16", pwm_freq=2000)
motor2 = Motor(dir_pin="P8_16", pwm_pin="P9_14", pwm_freq=2000)
motor3 = Motor(dir_pin="P8_14", pwm_pin="P8_13", pwm_freq=2000)
motor4 = Motor(dir_pin="P8_26", pwm_pin="P8_19", pwm_freq=2000)
So there…I think this will help too.
Seth
P.S. I think I am starting to understand the issue here. Simultaneously use the two, separate peripherals in question for the Cape. So, use the GPIO (P8_18) for ON/OFF and then PWM freq. and for digital out (P9_16) at the same time.
So, when you set your PWM pin to a specific state and frequency, then come along and try to set your GPIO pin HIGH or LOW. Maybe setting it low first would be smart. I do not know if it is smart at all actually. I usually just turn off all motors just in case to begin. So, clean slate and then consumption!
Something else I found interesting in the schematic are the inverters listed as 74LVC1G57.
I think their use on this Cape is interesting. So, it inverts in and comes out as many different forms of output. It is like a Catch-22. All the gates…
Oh! And I think this EEPROM issue is not of my concern (so far). I have not learned all that much about it thus far, esp. around this Cape. I see the address is 0x55. So, stacking two is plausible but have I configured it to run well w/ two Capes attached. well, no. I have not.
Hello Again @smanko ,
Seth here. I will stay patient while you set things up.
- Micro USB to USB cable for debugging.
- Barrel Jack 5v 2A for power.
- MotorCape with say 12v battery for using the DC Motor in question.
- Wires.
- Ethernet Cable for adjusting the OS, i.e. update/upgrade.
- Source
- Or…the way you want to do it.
a. w/ exporting your PWM peripheral
b. w/ exporting your GPIO pin and making it go high/low.
If you want me to test w/ the command export, I can try.
Just let me know what you think so far.
Seth
P.S. So, if you see the LED is ON via PWM and your bring your exported GPIO to HIGH, does it not work?
Hello again silver2row,
every point from your list was already done by me.
I finally found the failure in my configuration. The 5 V DC pin was missing. I had totally overlooked this in the schematic. So in summary the PWM, 3.3 V and 5 V pin are neccessary. The HIGH pin is mandatory.
Sadly my first motor cape still is defect, but the new one works quite well to drive motors, NOW.
For frequency, different values are working and the motor movement goes from bad to good.
With 20-50 Hz it’s moving like a bass shaker 
With 100-500 Hz it’s noise is quite hummy 
With 1-5 kHz it’s noise is quite squeaky 
With 20-50 kHz it’s OK, because the frequency is out of human hearing capabilities 
My next steps will be to implement the quadrature encoder again and write some software/script to do a motor positioning with slighly adjustable start/stop ramps including yerk. From reasearch I found it can be done in user space or (realtime) PRUS. If you have any hints or tips for software or where I can find some, please let me know.
1 Like
Hello @smanko ,
Seth here again. Um…look here: PRU Cookbook .
It is an older but functional display of PRUSS usage and may be able to help you.
Seth
1 Like