Linux/TMDSEVM572X: GPIO and UART signal output

The software team have been notified. They will respond here.

As a quick sanity check, can you please provide the output of this command:

devmem2 0x4A0036CC

This will give us the contents of CTRL_CORE_PAD_MCASP1_AXR6, the register that controls pin muxing for gpio5_8.

Did you ever set the direction, e.g. echo "out" > gpio136/direction?

root@am57xx-evm:~# devmem2 0x4A0036CC
/dev/mem opened.
Memory mapped at address 0xb6efe000.
Read at address 0x4A0036CC (0xb6efe6cc): 0x0004000E
root@am57xx-evm:~#

****** Modifications to Device Tree ******

/home/blahblah/ti-processor-sdk-linux-am57xx-evm-04.01.00.06/board-support/linux-4.9.41+gitAUTOINC+e3a80a1c5c-ge3a80a1c5c/arch/arm/boot/dts/am57xx-evm-reva3.dts
************************************************************

.
.
.

#include "am57xx-evm-cmem.dtsi"


&vmmcwl_fixed {
gpio = <&gpio5 9 GPIO_ACTIVE_HIGH>; (Jeff - This was defined gpio 5 8, and causing a conflict with sysfs, so I moved it to 5 9)
enable-active-high;
};

&gpio5 {
ti,no-reset-on-init;
ti,no-idle-on-init;
gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>;
};

****** SSH Session on Target ********
root@am57xx-evm:/sys/class/gpio# echo 136 > export ( Jeff - I understand 136 to be gpio5 8 = (5-1)*32 + 8 = 136 )
root@am57xx-evm:/sys/class/gpio# ls

export gpiochip0 gpiochip192 gpiochip504 unexport
gpio132 gpiochip128 gpiochip224 gpiochip64
gpio136 gpiochip160 gpiochip32 gpiochip96

root@am57xx-evm:/sys/class/gpio# echo out > gpio136/direction
root@am57xx-evm:/sys/class/gpio# echo 1 > gpio136/value
root@am57xx-evm:/sys/class/gpio# echo 0 > gpio136/value

Note: The voltage state of Pin #55 on Expansion Header P17 does not change in response to changing the value file..



Thanks!!!

Jeff Andich said:

root@am57xx-evm:/sys/class/gpio# echo out > gpio136/direction
root@am57xx-evm:/sys/class/gpio# echo 1 > gpio136/value
root@am57xx-evm:/sys/class/gpio# echo 0 > gpio136/value

Please repeat this process, but use devmem2 to dump the following registers at the start and after each step:

• 0x4805B130 (GPIO_CTRL)
• 0x4805B134 (GPIO_OE)
• 0x4805B138 (GPIO_DATAIN)
• 0x4805B13C (GPIO_DATAOUT)

I would have expected gpio136 to be the right number, but that may not be the case.  In fact, now that I'm thinking about it, I seem to recall a similar thread where the pin mappings changed because some of the GPIO peripherals were unused (or idle?).  I need to do some more digging...

I haven't found that other thread, but I think it might be worth adding something like this into your dts:

&gpio1 {
status = "okay";
}

&gpio2 {
status = "okay";
}

&gpio3 {
status = "okay";
}

&gpio4 {
status = "okay";
}

&gpio5 {
status = "okay";
}

I think that will ensure that all of the gpio's are "present" when doing the pin mapping.

This might be the thread I was thinking of:

e2e.ti.com/.../611907

Perhaps I remembered incorrectly of the mapping having anything to do with which GPIO modules are enabled, etc. I don't see anything like that. One good data point from that thread however is to simply do:

ls -l /sys/class/gpio

You'll see mappings like this:

gpiochip128 -> ../../devices/platform/44000000.ocp/4805b000.gpio/gpio/gpiochip128

So the specific mapping I showed above confirms that the GPIO5 peripheral (base address 0x4805B000) maps to gpiochip128. Do you see the same on your board?

Brad

Ok thanks! I added statius = okay to the &gpio5 cluster/fragment in am57xx-evm-reva3.dts, compiled on host, scp'ed to /boot on the EVM, and re-booted. Here is the output of executing the above commands before and after each of the sysfs commands:


****** Before Issuing any SYSFS Commands *****

root@am57xx-evm:~# devmem2 0x4805B130
/dev/mem opened.
Memory mapped at address 0xb6f5f000.
Read at address 0x4805B130 (0xb6f5f130): 0x00000000
root@am57xx-evm:~#
root@am57xx-evm:~#
root@am57xx-evm:~# devmem2 0x4805B134
/dev/mem opened.
Memory mapped at address 0xb6f25000.
Read at address 0x4805B134 (0xb6f25134): 0xFFFFFDEF
root@am57xx-evm:~#
root@am57xx-evm:~# devmem2 0x4805B138
/dev/mem opened.
Memory mapped at address 0xb6fc5000.
Read at address 0x4805B138 (0xb6fc5138): 0x0403001F
root@am57xx-evm:~#
root@am57xx-evm:~# devmem2 0x4805B13C
/dev/mem opened.
Memory mapped at address 0xb6f0d000.
Read at address 0x4805B13C (0xb6f0d13c): 0x00000410


***** After creation of gpio136 file ****

root@am57xx-evm:/sys/class/gpio# echo 136 > export
root@am57xx-evm:/sys/class/gpio# ls
export gpiochip0 gpiochip192 gpiochip504 unexport
gpio132 gpiochip128 gpiochip224 gpiochip64
gpio136 gpiochip160 gpiochip32 gpiochip96

root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B130
/dev/mem opened.
Memory mapped at address 0xb6fe1000.
Read at address 0x4805B130 (0xb6fe1130): 0x00000000
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B134
/dev/mem opened.
Memory mapped at address 0xb6fcf000.
Read at address 0x4805B134 (0xb6fcf134): 0xFFFFFDEF
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B138
/dev/mem opened.
Memory mapped at address 0xb6f3d000.
Read at address 0x4805B138 (0xb6f3d138): 0x0003001F
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B13C
/dev/mem opened.
Memory mapped at address 0xb6f67000.
Read at address 0x4805B13C (0xb6f6713c): 0x00000410



***** After Changing Direction to Out *****

root@am57xx-evm:/sys/class/gpio# cat gpio136/direction
in
root@am57xx-evm:/sys/class/gpio# echo out > gpio136/direction
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B130
/dev/mem opened.
Memory mapped at address 0xb6f9d000.
Read at address 0x4805B130 (0xb6f9d130): 0x00000000
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B134
/dev/mem opened.
Memory mapped at address 0xb6f2a000.
Read at address 0x4805B134 (0xb6f2a134): 0xFFFFFCEF
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B138
/dev/mem opened.
Memory mapped at address 0xb6fd7000.
Read at address 0x4805B138 (0xb6fd7138): 0x0003001F
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B13C
/dev/mem opened.
Memory mapped at address 0xb6fc7000.
Read at address 0x4805B13C (0xb6fc713c): 0x00000410

**** After changing the value file from 0 to 1 *****
root@am57xx-evm:/sys/class/gpio# cat gpio136/value
0
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# echo 1 > gpio136/value
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B130
/dev/mem opened.
Memory mapped at address 0xb6f40000.
Read at address 0x4805B130 (0xb6f40130): 0x00000000
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B134
/dev/mem opened.
Memory mapped at address 0xb6fde000.
Read at address 0x4805B134 (0xb6fde134): 0xFFFFFCEF
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B138
/dev/mem opened.
Memory mapped at address 0xb6fe6000.
Read at address 0x4805B138 (0xb6fe6138): 0x0003011F
root@am57xx-evm:/sys/class/gpio#
root@am57xx-evm:/sys/class/gpio# devmem2 0x4805B13C
/dev/mem opened.
Memory mapped at address 0xb6fb3000.
Read at address 0x4805B13C (0xb6fb313c): 0x00000510
root@am57xx-evm:/sys/class/gpio#


Thanks!!

Were you observing the GPIO5_8 output during those commands? Everything looks proper above. For example, when you change the GPIO to an output, you can see bit 8 of GPIO_OE becomes 0 (output enabled). When you write the value, I see that correctly reflected in dataout (and datain).

Yes, that's most of the battle.


But no - I didn't observe pin 55 on the P17 header change when I tried echoing 1 vs 0 > gpio136/value... (...wah wah...) ..


I wonder if this could be our breakout board, but I ohm'd out the connectors on our breakout PCBA, and I didn't see any issues there. But it's just a simple, single layer board, and we didn't take any extraordinary measures to isolate high frequency signals from trace to trace. Nonetheless, I would expect changes in the pins assigned to GPIO voltages to change. But also keep in mind that we're running the latest SDK image, likely with Matrix running.

I wonder if the PAD on the 5728 for GPIO5_8 is connected to the P17 expansion header per the RevA3 schematic. Reason I ask:

The GP EVM UG, www.ti.com/.../spruig1.pdf in table 21 indicates WL_EN, COM port WLAN enable. But I don't THINK TMDSEVM572X has a WiFi chip on it?? Furthermore, many of the signals in the 3 expansion header tables in this UG indicate "Not Connected." I'm not sure if this means not connected to another peripheral OR the associated 5728 PAD is not connected to the indicated pin on the expansion header???

Another potentially interesting point, on our PCBA expansion board (which breaks out 30/60 signals), I'm able to see what I believe are LCD video signals on the VOUTn_Dn lines, but also some other lines as well which are inputs (please see below).

For instance:

Our breakout board breaks out the following pins on each expansion header

TP(9,10,11,14,15,17,18,20,21,
22,23,25,27,29,30,39,40, 44,
45,47,50,52,55,56,57,59,60)

When I'm running the latest TI SDK image (create SD card from pre-installed binaries option), I see what I think is LCD video signals on the following pins on the *** P18 HEADER *****: Again, I believe MATRIX is enabled/running.

root@am57xx-evm:/sys/class/gpio# ps -aux|grep matrix
root 939 0.0 2.3 166436 44560 ? Sl 21:43 0:01 /usr/bin/matrix_browser http://localhost:80/


*** P18 HEADER PINS where an LCD Video Signal is Thought to be Observed:***
(to the right is the corresponding entry in core_padconf_array_essential_x15 (in the case of non-VOUT/VIN signals which are in a "delta" array).

9 (GPIO3_29) {VIN2A_DE0, (M14 | PIN_INPUT_PULLDOWN)}, /* vin2a_de0.gpio3_29 */
10 (PR1_UART0_TXD) {VIN2A_D1, (M11 | PIN_OUTPUT)}, /* vin2a_d1.pr1_uart0_txd */
11 (GPIO3_28) {VIN2A_CLK0, (M14 | PIN_INPUT_PULLDOWN)}, /* vin2a_clk0.gpio3_28 */
14 (VOUT1_D15)

39 (GPIO4_8) {VIN2A_D7, (M14 | PIN_INPUT_PULLDOWN)}, /* vin2a_d7.gpio4_8 */
40 (PR1_UART0_CTSn) {VIN2A_D7, (M14 | PIN_INPUT_PULLDOWN)}, /* vin2a_d7.gpio4_8 */
44 ( EHRPWM2B) {VIN2A_D10, (M10 | PIN_OUTPUT_PULLDOWN)}, /* vin2a_d10.ehrpwm2B */

45 (VOUT1_D6)
47 (VOUT1_D8)

Incidentally, we thought we might as well try different pullup/pulldown states of GPIO5_8, IN 4a00 36cc:

We hacked the corresponding line in mux_data.h, re-built the MLO/u-boot.image, copied to the /boot partition on SD card, and then inserted in the 572xEVM, and powered on.

..board/ti/am57xx/mux_data.c (padconf_array_essential....)
/** PD is default entry and has no effect **/
/* {MCASP1_AXR6, (M14 | PIN_INPUT_PULLDOWN)}, */ /* mcasp1_axr6.gpio5_8 */
/** PU has no effect **/
/* {MCASP1_AXR6, (M14 | PIN_INPUT_PULLUP)}, */ /* mcasp1_axr6.gpio5_8 */
/** Disable weak PU PD */
{MCASP1_AXR6, (M14 | PIN_INPUT_PULLUP | PULL_DIS)}, /* mcasp1_axr6.gpio5_8 */



PULL UP:

root@am57xx-evm:~# devmem2 0x4A0036CC
/dev/mem opened.
Memory mapped at address 0xb6f7f000.
Read at address 0x4A0036CC (0xb6f7f6cc): 0x0006000E

root@am57xx-evm:/sys/class/gpio# echo out > gpio136/direction
root@am57xx-evm:/sys/class/gpio# cat gpio136/value
0
root@am57xx-evm:/sys/class/gpio# echo 1 > gpio136/value


Result: No change in voltage on P17 header, Pin #55,


NO PULL:

root@am57xx-evm:~# devmem2 0x4A0036CC
/dev/mem opened.
Memory mapped at address 0xb6fbc000.
Read at address 0x4A0036CC (0xb6fbc6cc): 0x0007000E

(Think all we care about is bit #16 being a 1 (no pull) or 0 (pull as defined by bit #17), right?


Result:

root@am57xx-evm:/sys/class/gpio# echo out > gpio136/direction
root@am57xx-evm:/sys/class/gpio# echo 0 > gpio136/value
root@am57xx-evm:/sys/class/gpio# echo 1 > gpio136/value

No change in P17/Pin 55 voltage..


Thanks and FYI!

One more crazy thought/question:

When using the expansion header(s) on the 572xEVM Processor Module, do you have to tie certain signals on all 4 headers together?

I've just been plugging in my breakout board into a single expansion port at a time, and leaving all of the other expansion headers disconnected.

But I don't know what the LCD/Touchscreen does (e.g. How it completes the circuit of the expansion headers) and am not sure where to find the schematic for it. Is this maybe a piece of the puzzle??

Thanks!

I don't think there's any black magic with respect to this pin on the LCD card. However, those schematics are available here if you'd like to look:

www.ti.com/.../tidria3

Specifically, they are found at tidria3c.zip\CM_C1 LM_A2a PM_A3a\AM572xEVM_LM\ti_am572x_evm_lm_a2a.pdf.

Let's try a slightly different experiment... From the schematic, it looks like gpio5_8 is routed directly from the AM572x to the header (i.e. no pullup/pulldown, etc.). That said, we should be able to observe behavior by activating deactivating the driver and changing the internal pull. This is similar to your test you tried with changing the u-boot muxing, but we want to set the mux mode to 15 (driver off). This can be done quickly/easily using devmem2, i.e. no need to rebuild/reload u-boot...

# weak pulldown
devmem2 0x4a0036cc w 0x0000000F

# weak pullup
devmem2 0x4a0036cc w 0x0002000F

That should absolutely work... If that is STILL not working, I suggest we try that similar experiment on a different pin (since it's fairly easy).

Jeff Andich said:

I wonder if the PAD on the 5728 for GPIO5_8 is connected to the P17 expansion header per the RevA3 schematic. Reason I ask:

The GP EVM UG, www.ti.com/.../spruig1.pdf in table 21 indicates WL_EN, COM port WLAN enable. But I don't THINK TMDSEVM572X has a WiFi chip on it??

The AM572x EVM has a connector on the LCD board in which you could plug a TI Wi-Fi Board.  I've plugged a wi-fi board into that connector and used it, so that confirms the signal is truly usable.  In fact, that WL_EN pin is just a GPIO pin in the Linux driver, so we know specifically that it works in the GPIO mode.

Cool! was wondering how you could write to the pad control registers from user space..

Well, nothing happens to the voltage on that pin with either of these w commands...

Time to try another pin...

How about one of the pins I see LCD video signals on (e.g. gpio3_29 or VOUT_D15 )?

I think gpio3_29 looks good since it has no external pulls. The associated register is CTRL_CORE_PAD_VIN2A_DE0 at 0x4A003558.

So this is strange. I tried setting mux mode to 15 on P18, pin 14 (VOUT1_D15), and I still see a 15ms pulse train, each pulse containing several periods of an ~83 kHz, 75% duty cycle clock.

And likewise with P18/Pin #9 - still see this strange signal (which I thought was LCD video) on the scope. I will try to take a screen capture of this signal and attach to this thread..

I'm running out of suggestions, so if that's the case I'll be relieved!

Pin #9 on P18 is gpio3_29. Rotated 180 degrees, this is pin 52 or vout1_d22. When I change it's pad to mux mode 15, the clock signal stops.

I feel terrible, and I think I owe you a pizza...

No problem. There's some good debug procedure in this thread that might help other people.

In any case thanks a whole lot for your help!!