how to make pwm_P8_13 low on boot?

122 views
Skip to first unread message

janszyma...@gmail.com

unread,
Nov 23, 2014, 5:58:19 PM11/23/14
to beagl...@googlegroups.com
Hi,

I'm trying to use pwm on BBB
Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l GNU/Linux
I have modified uEnv.tx
...
cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm
...
and /etc/default/capemgr
...
# Options to pass to capemgr
CAPE=SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm
...

after booting I have correctly in slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
10: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P8_13
11: ff:P-O-L Override Board Name,00A0,Override Manuf,am33xx_pwm
12: ff:P-O-L Override Board Name,00A0,Override Manuf,SPI-4SS
13: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_eqep2b

and pwm works, but,

- after power on the logic level on P8_13 is low (as I want it to be)
- after that (loading dtc overlay) the logic level on P8_13 become high (I dont want it)

My attempt to modify  /lib/firmware/bone_pwm_P8_13-00A0.dts and then recompiling doesn't effect any of:
/sys/devices/ocp.3/pwm_test_P8_13.11/ duty, period, polarity, run, ....

As I don't want the motor connected to PWM to run, before the applications takes over the control,
can anyone help me to achieve it?

Jan



janszyma...@gmail.com

unread,
Nov 23, 2014, 11:26:08 PM11/23/14
to beagl...@googlegroups.com, janszyma...@gmail.com
the values in /sys/devices/ocp.3/pwm_test_P8_13/11 are:
duty 0
period 500000
polarity 1
run 1
after the device tree overlay is loaded.
Does anyone know if possible and if yes how to change them (the default values)?
The changes to corresponding *.dtbo file doesn't change them.

Peter Gregory

unread,
Nov 25, 2014, 8:34:02 AM11/25/14
to beagl...@googlegroups.com
I don't know if this will help, but have you tried changing the polarity of the PWM pin in the device tree overlay?

bs_pwm_test_P8_13 {
compatible = "pwm_test";
pwms = <&ehrpwm2 1 500000 0>;
pwm-names = "PWM_P8_13";

pinctrl-names = "default";
pinctrl-0 = <&bs_pwm_P8_13_0xc>;

enabled = <1>;
duty = <0>;
status = "okay";
};


The last numeric parameter of pwms <&ehrpwm2 1 500000 0> swaps the polarity of the PWM output.
With the default duty cycle of 0, the pin will be low on power-up.

Jason Lange

unread,
Nov 25, 2014, 4:45:34 PM11/25/14
to Beagle Board
- after power on the logic level on P8_13 is low (as I want it to be)
- after that (loading dtc overlay) the logic level on P8_13 become high (I dont want it)

Sorry, I missed this.  The 74HC04 would work if it started high and stayed that way.  Do you need to use an overlay?  Maybe if you modified the initial device tree, perhaps with Roberts system for the 3.14 kernel it would start high and you could flip it.

janszyma...@gmail.com

unread,
Nov 25, 2014, 5:08:42 PM11/25/14
to beagl...@googlegroups.com, janszyma...@gmail.com
 Thanks Peter,

 I have exercised that option already before posting and somehow it didn't work.

Changing the parameters (and recompiling) didn't change the default values, so my conclusion is that they might be

somehow hard-coded in a kernel driver.

Jan


On Monday, 24 November 2014 09:58:19 UTC+11, janszyma...@gmail.com wrote:

janszyma...@gmail.com

unread,
Nov 25, 2014, 5:14:44 PM11/25/14
to beagl...@googlegroups.com
Thanks Jason,

 There is a hardware solution to my problem in a form of a tiny logic 08 (AND gate). The PWM is connected to one input and an extra ENABLE signal from GPIO is connected to another input. On the output the resulting gated PWM signal will appear when the ENABLE signal goes high from the application.
The solution however is non-elegant and can be avoided if I had a better knowledge of the software - in this case a PWM driver and it's interaction with a device tree overlay.

The inverter is not a solution as on boot initial pin value is low and after the device tree is loaded it jumps high until the application software (controlling pwm) takes over.
I will use it as a temporary solution.

Cheers

Jan
Message has been deleted

Peter Gregory

unread,
Nov 25, 2014, 6:02:27 PM11/25/14
to beagl...@googlegroups.com
I had the same issue driving RBG Leds.
They were starting turned on full force since the PWM was driving high on boot.
Changing the polarity worked for me.

Is it possible the order of overlays is undoing your changes to bone_pwm_P8_13?
Instead of:

cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm

Maybe try it with your modifications being the last overlay to load:

cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,am33xx_pwm,bone_pwm_P8_13

janszyma...@gmail.com

unread,
Nov 25, 2014, 7:28:44 PM11/25/14
to beagl...@googlegroups.com
thanks, unfortunately didn't work for me.

Miguel Aveiro

unread,
Nov 25, 2014, 9:26:58 PM11/25/14
to beagl...@googlegroups.com
It's not a kernel driver, I believe it's the processor default mode. You can check the processor datasheet:
http://www.ti.com/product/AM3359/datasheet/terminal_description?search=pin,default#sprs717824

If you want to change it earlier than linux, you need to set the pin in uboot (as far as I can understand). You can check the list because I know that I have already read something about change default IO in BBB. Or something about u-boot and gpio, like this:
http://www.crashcourse.ca/wiki/index.php/U-Boot_on_the_BBB

Hopefully, this can help a little....

Miguel Aveiro
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

William Hermans

unread,
Nov 25, 2014, 10:43:21 PM11/25/14
to beagl...@googlegroups.com
IN short, use external hardware or do something cleaver like Peter G, and reverse polarity. *OR* have an external "switch" that switches the PWM line off, until you tell it to turn on. simples ?

Jon E

unread,
Nov 26, 2014, 4:29:31 AM11/26/14
to beagl...@googlegroups.com
I'm not sure about that. Jan said before that it's only driven high after loading the PWM driver, and the processor datasheet shows ball T10 (P8_13) as driven low during/after reset. 

Jan, not ideal, but to disable the output sooner you could load the overlay through cape manager, and then write 0 to the run parameter immedately afterwards. But I still think the correct approach is to look at the devcetree/driver code and see why those parameters are having no affect..

Regards,
Jon

janszyma...@gmail.com

unread,
Nov 26, 2014, 5:11:26 AM11/26/14
to beagl...@googlegroups.com
Good idea, thanks. I will try it. I think the positive pulse will be so short that it will not be able to move the motor.

Jon Escombe

unread,
Dec 4, 2014, 1:34:44 PM12/4/14
to beagl...@googlegroups.com, janszyma...@gmail.com
Hi Jan,

I had another look at this, was able to replicate what you are seeing,
and think I know what's going on..

The part-number 'bone_pwm_P8_13' is already included in the kernel
build. I'm not really sure of the mechanics, but when doing a build from
the git repository, all the .dts files in the /firmware/capes folder get
compiled to individual .dtbo files, and from there into object files,
and then combined into a single built-in.o file.

The end result of this appears to be that putting an overlay file for
one of these built-in part-numbers into /lib/firmware doesn't achieve
anything, it just doesn't get read (even if you increment the version).

Anyway, it's an easy fix - once you know what's going on!! You should
just need to change the part-number to something else unique (and the
file name to suit), and then the options can be set in your overlay as
you'd expect..

Hope this helps,
Jon.

janszyma...@gmail.com

unread,
Dec 4, 2014, 4:37:33 PM12/4/14
to beagl...@googlegroups.com, janszyma...@gmail.com
Jon,

 Thank you for your valuable input.
I will try it soon and let you know.
The obvious question already is which one will take precedence in loading:
the overlay defined in the kernel or the one handled by the cape manager?

Cheers,

Jan

Robert Nelson

unread,
Dec 4, 2014, 4:39:00 PM12/4/14
to Beagle Board, Jan Szymanski
On Thu, Dec 4, 2014 at 3:37 PM, <janszyma...@gmail.com> wrote:
> Jon,
>
> Thank you for your valuable input.
> I will try it soon and let you know.
> The obvious question already is which one will take precedence in loading:
> the overlay defined in the kernel or the one handled by the cape manager?

The one built-in..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

janszyma...@gmail.com

unread,
Dec 4, 2014, 5:09:14 PM12/4/14
to beagl...@googlegroups.com, janszyma...@gmail.com
Thanks Robert,

Is there a way to overwrite it?
How can I tell which ones are builtin (so I can select another PWM module and pin)?

Jan

Robert Nelson

unread,
Dec 4, 2014, 5:10:53 PM12/4/14
to Beagle Board, Jan Szymanski
On Thu, Dec 4, 2014 at 4:09 PM, <janszyma...@gmail.com> wrote:
> Thanks Robert,
>
> Is there a way to overwrite it?

Rename your local version..

> How can I tell which ones are builtin (so I can select another PWM module
> and pin)?

You can see them here:

https://github.com/beagleboard/linux/tree/3.8/firmware/capes

janszyma...@gmail.com

unread,
Dec 4, 2014, 6:21:53 PM12/4/14
to beagl...@googlegroups.com, janszyma...@gmail.com
OK, I did the renaming from "bone_pwm_P8_13-00A0.* " into "bone_pwm_test-00A0.*" and after reboot I have:

in slots:
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
 8: ff:P-O-L Override Board Name,00A0,Override Manuf,SPI-4SS
 9: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_eqep2b
10: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_test

11: ff:P-O-L Override Board Name,00A0,Override Manuf,am33xx_pwm

but in  /sys/devices/ocp.3/pwm_test_P8_13.16 I have only:

root@beaglebone:/sys/devices/ocp.3/pwm_test_P8_13.16# ls
modalias  power  subsystem  uevent

My bone_pwm_test-00A0.dts and bone_pwm_test-00A0.dtb0 are in /lib/firmware
Do I need to make any changes to them after all (as the renaming only doesn't work)?

Jan

Jon Escombe

unread,
Dec 4, 2014, 6:54:39 PM12/4/14
to beagl...@googlegroups.com, janszyma...@gmail.com
I used roughly the following process;

1) grab the original source file & copy to a local version

wget
https://raw.githubusercontent.com/beagleboard/linux/3.8.13-bone66/firmware/capes/bone_pwm_P8_13-00A0.dts

cp bone_pwm_P8_13-00A0.dts bone_pwm_local-00A0.dts

2) change the part-number in your local version of the .dts file

< part-number = "bone_pwm_P8_13";
---
> part-number = "bone_pwm_local_P8_13";

3) compile & copy to /lib/firmware

dtc -O dtb -o bone_pwm_local-00A0.dtbo -b 0 -@ bone_pwm_local-00A0.dts

cp bone_pwm_local-00A0.dtbo /lib/firmware/

4) load the am33xx_pwm overlay, plus your local config for your pin

echo am33xx_pwm >/sys/devices/bone_capemgr.*/slots
echo bone_pwm_local >/sys/devices/bone_capemgr.*/slots

Those steps should be enough;

root@beaglebone:~# ls /sys/devices/ocp.*/pwm_test_P8_13.*/
driver duty modalias period polarity power run subsystem uevent

Regards,
Jon

janszyma...@gmail.com

unread,
Dec 4, 2014, 7:21:36 PM12/4/14
to beagl...@googlegroups.com, janszyma...@gmail.com
Hi Jon,
Thanks, that works and behaves exactly as I need.
Jan
Reply all
Reply to author
Forward
0 new messages