On Tue, Apr 25, 2017 at 11:34 AM, ThomasL <lapauwtho...@gmail.com> wrote:
> Hi,
>
> We are trying to get the GPIO toggle example running on the beaglebone
> black.
>
> At this point we succeeded in the following: running the RProc echo
> example from the TI hands on lab which works. Writing and loading a custom
> device tree overlay to set the pinmux although we are not sure whether the
> pins get configured correctly.
>
> We did some tests by setting the pinmode with pull-up and pull-down
> resistors which we measured using a multimeter. So we are sure the device
> tree overlay is loaded correctly. But we are not able to toggle pins from
> the PRU.
>
> The device tree overlay code (PRU cape dtsi file adapted to overlay):
>
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> part-number = "EMS-PRU-CUSTOM";
> version = "00A0";
>
> /* This overlay uses the following resources */
> exclusive-use =
> "P9.30",
> "P9.31",
> "P9.27",
> "P9.25",
> "P9.29",
> "P9.28",
> "P8.44",
> "P8.41",
> "P8.42",
> "pru0",
> "pru1",
> "pruss";
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pru_pru_pins: pinmux_pru_pru_pins { // The PRU pin modes
> pinctrl-single,pins = <
> 0x1a4 0x2e /* mcasp0_fsr, OMAP_MUX_MODE6 | AM33XX_PIN_INPUT,
> PRU CAPE SW1 */
> 0x1ac 0x2e /* mcasp0_ahclkx, OMAP_MUX_MODE6 | AM33XX_PIN_INPUT, PRU CAPE
> SW2 */
> 0x19c 0x05 /* mcasp0_ahclkr, OMAP_MUX_MODE5 | AM33XX_PIN_OUTPUT, PRU CAPE
> Red LED */
> 0x198 0x05 /* mcasp0_axr0, OMAP_MUX_MODE5 | AM33XX_PIN_OUTPUT, PRU CAPE
> Orange LED */
> 0x190 0x05 /* mcasp0_aclkx, OMAP_MUX_MODE5 | AM33XX_PIN_OUTPUT, PRU CAPE
> Blue LED */
> 0x194 0x05 /* mcasp0_fsx, OMAP_MUX_MODE5 | AM33XX_PIN_OUTPUT, PRU CAPE
> Green LED */
> 0x0ac 0x05 /* lcd_data3, OMAP_MUX_MODE5 | AM33XX_PIN_OUTPUT, PRU CAPE
> RGB_0 LED, HDMI Conf. */
> 0x0b0 0x05 /* lcd_data4, OMAP_MUX_MODE5 | AM33XX_PIN_OUTPUT, PRU CAPE
> RGB_1 LED, HDMI Conf. */
> 0x0b4 0x05 /* lcd_data5, OMAP_MUX_MODE5 | AM33XX_PIN_OUTPUT, PRU CAPE
> RGB_2 LED, HDMI Conf. */
> >;
> };
> };
> };
>
> fragment@1 { // Enable the PRUSS
> target = <&pruss>;
> __overlay__ {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&pru_pru_pins>;
> };
> };
>
>
> };
>
>
> The code of the GPIO toggle example remained the same (toggling some bits
> of R30 ). The outfile was moved to /lib/firmware and symlinked to
> am335x-pru0-fw which was then loaded by removing and reloading pru_rproc.
>
> Is there a way to check how the pinmux is configured? Also using the
> uEnv.txt we prevented any universal capes from loading on boot
> (cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=disable) and
> are using dtb=am335x-boneblack-overlay.dtb
>
>
> We are running out of ideas why the GPIO's are not toggling. Perhaps
> something is missing in the dts file? Are we overlooking something?
>
> Thanks in advance
>
I think the solution that Greg offered would probably work, but is also in
my own mind a hack at best. The problem with config-pin is that you have to
wait for the system to be up and running, along with cape-mgr, and god know
what else. With an overlay, you can configure your pin through the second
stage boot loader much sooner, and you can configure the pins on your board
all at once, and exactly to your specification. Hi, low, etc. So I tend to
agree with you, that yes, the best solution is to go with an overlay.
There are also other aspects to this situation that may be less than
desirable. Such as knowing the script you're using ( config-pin ), and
potential legal issues using that software in a commercial application.
Blah blah blah. . . So I'm not saying these are real problems, just that
it's other information one needs to know before using third party software
to feel OK with using that third party software. Something that software
engineers do not necessarily want, or need to deal with.
Anyway Thomas, I think your problem may stem from universal overlays being
enabled by default. You want your cmdline= line in /boot/uEnv.txt to look
somethign like this:
cmdline=coherent_pool=1M net.ifnames=0 quiet
Initially, it'll look like this:
cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable
Remove the cape_universal=enable bit from that line.
Additionally, you'll want to know which board overlay file you're loading
at boot. Again, at the top of the /boot/uEnv.txt file you'll see some
commented out entries like these:
##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb
##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb
##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb
##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb
##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb
##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb
You can comment out one of these which is applicable to you. So let's say
the pin your using is a part of hdmi audio, or video. You're going ot need
to disable that by selecting the correct board overlay file from the listed
above. Sp if you wanted to get back your pins from hdmi video and audio you
would uncomment this like so:
##BeagleBone Black: HDMI (Audio/Video) disabled:
dtb=am335x-boneblack-emmc-overlay.dtb
In addition to that, if you're using uboot overlay loading I do believe you
can simply ignore the line which I just mentioned. Then use uncomment the
following lines instead:
*From:*
###Disable auto loading of virtual capes (emmc/video/wireless)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
*To:*
###Disable auto loading of virtual capes (emmc/video/wireless)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
So I do not know what peripherals can be muxed on the pin you're using
there. I do not have my muxing table PDF files handy at the moment, but you
can check that for yourself. Make sure nothing else is conflicting with
that pin for the "normal" default setting on your given image. Chances are
pretty good that since it seems to work with config-pin, but not without,
that the universal IO overlay is conflicting with your own overlay. You
could attempt to load your custom overlay from teh command line to see if
you get a "file already exists" error, and if you do, then there is a 99.9%
chance that universal IO being loaded at boot is your problem. If by some
odd chance it's not, there is another overlay overlay conflicting with that
which you desire.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CALHSORrpopoXpwqHC0rQA5%2Ba6CRq513nRa743-YQSiegqOCMfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
