On Tuesday, December 5, 2017 at 6:25:17 PM UTC-6, Jeff Andich wrote:
>
> Note: Per the 572xEVM_REVA3 schematic and the pad configuration of our
> boot loader, gpio5_8 comes out on pin 55 of the P17 expansion header on the
> BB-X15.
>
> Incidentally, I tried varying the brightness in
> /sys/class/leds/gpio_jeff_test to see if the level of gpio5_8 would change
> on the scope, but no luck Varying the brightness works great with the
> blinking leds (gpio7_8, 7_9, 7_14, 7_15) on the top of the bb-x15. You can
> turn them on an off by echoing different values in for "brightness."
>
> I was wondering if the expansion headers could be mis-labled on my board.
> So I tried moving the breakout board around to all 4 of the expansion
> headers, but keeping the scope probe on the same pin, pin55. But no luck.
>
> I also tried the ADAFRUIT GPIO module in Python, yesterday, but it looks
> like there isn't yet a Python module which exposes all of the gpio chips
> for the BB-X15. Please correct me if I'm wrong.
>
> Also, I have the following gpio fragment in my dts.
>
> &gpio5 {
> ti,no-reset-on-init;
> ti,no-idle-on-init;
> };
>
> Maybe a reasonable next-step is to find some known signals coming out on
> the expansion headers, and then reverse engineer how they're getting
> generated.. Maybe video signals or touchscreen input signals for the
> external touchscreen would be a good place to start....
>
> Thanks!
>
>
> On Monday, December 4, 2017 at 5:49:59 PM UTC-6, Jeff Andich wrote:
>>
>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/d7b37bb5-66b8-4488-9d89-cfa606b56a93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
