Hi,

Has anyone had any difficulty outputting GPIO,UART, I2C, signals from the 
BB-X15's expansion header?  I haven't yet been able to successfully get 
GPIO and/or UART data to come out on the associated pins of the 4 expansion 
ports of the am572xEVM/BB-X15.  We made a PCBA breakout board which breaks 
out 30/60 signals on each header. 

If you were able to get this working, what were some of the key 
considerations?

I stumbled across this post on TI E2E, where others were encountering 
issues with this as well.

https://e2e.ti.com/support/embedded/linux/f/354/p/595855/2206686#pi317016=1 

Here I THINK the TI employee indicated that one of the critical steps is 
specifying the correct offset in the device tree for the pad configuration 
register of interest.  But when I look at the device tree, 
am57xx-evm-reva3, and the associated included dtsi and dts files, I didn't 
see this kind of thing for GPIO pins:

        gpio5_pins: pinmux_gpio5_pins {
                pinctrl-single,pins = <
                        DRA7XX_CORE_IOPAD(0xNNNN, (PIN_INPUT | MUX_MODEX))
                        DRA7XX_CORE_IOPAD(0xNNNN, (PIN_OUTPUT| MUX_MODE3))
                >;
        };


in the case of attempting to set GPIO5_8, and using sysfs commands, echo 
1,0 > /sys/class/gpio/gpio136/value (after setting the direction to OUT), 
the value and direction files always jive with what gets echo'd into the 
file - however the state of the line doesn't change.

I DO have a modified board.c file, but I'm pretty confident the pinmux in 
mux_data.h for GPIO5_8 is the same as the development board.  Granted this 
maybe an older revision, as I grabbed one of the earlier revisions of 
u-boot 2017.01.
 
I even tried hacking,  am57xx-beagle-x15-common.dtsi by adding another 
phantom LED fragment/cluster.

.
.
.
        leds {
        .
        .
        .
          led@4 {
                        label = "gpio_jeff_test";
                        gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
                        linux,default-trigger = "ide-disk";
                        default-state = "off";
                };
        };

The good news is, the  gpio line is 3.3V with this statement.
The bad news: When I change this to GPIO_ACTIVE_LOW, gpio5_8 is still stuck 
at 3.3V..


The only luck I've had to date is on our custom hardware board, coupling 
GPIO5_8 with UART5 for the rts line, and then toggle the GPIO line via 
sysfs commands and by toggling the state of the rtscts flag in Pyserial in 
Python (This after swapping out the 8250 serial driver for the OMAP driver):

&uart5 {
        pinctrl-names = "default";
        pinctrl-0 = <&uart5_pins>;
        status = "okay";
      rts-gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>;
        rs485-rts-active-high;
        rs485-rts-delay = <0 0>;
        linux,rs485-enabled-at-boot-time;
};


Can you maybe provide any clues to steer us in the right direction?


Thanks!!!

Jeff

-- 
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/8b4bfaa6-260e-4a41-b0eb-02f67f316e03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to