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?
Maybe try it with your modifications being the last overlay to load:
thanks, unfortunately didn’t work for me.
It’s not a kernel driver, I believe it’s the processor default mode. You can check the processor datasheet:
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: Hopefully, this can help a little… Miguel Aveiro
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 ?
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…
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.
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,
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?
Is there a way to overwrite it?
How can I tell which ones are builtin (so I can select another PWM module and pin)?
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
You can see them here:
OK, I did the renaming from "bone_pwm_P8_13-00A0.* " into “bone_pwm_test-00A0.*” and after reboot I have:
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:
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)?
I used roughly the following process;
1) grab the original source file & copy to a local version
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";
Thanks, that works and behaves exactly as I need.