Still investigating this. Still no luck with getting GPIO or UART to come
out on the corresponding pins on the expansion header with our PCBA
breakout board.
I'll try to write up what I've found thus far by end of today (or by
Sunday).
In the meantime, just taking a poll:
Who here has successfully gotten her/his BeagleBoard-X15 to output known
signals on the expansion header pin?
Any information would be greatly appreciated. Even a "Yes this worked fine
for me," would be helpful!
On Tuesday, December 5, 2017 at 6:28:00 PM UTC-6, Jeff Andich wrote:
>
>
>
> 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/3cdf255f-4aff-49d0-a881-91ba8b86e18f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
