CODEWITHSUNDEEP
linuxserial-portembedded-linuxuarttexas-instruments
Brad Grissom
Brad Grissom

Reputation: 3963

UART3 RX being held hi (strong pullup) on TI Omap AM335x Sitara Variscite Dev board

I have a

and I'm trying to get UART3 to work with a

Summary of the puzzling part: I am also working on a custom SoM carrier board based on this Variscite dev board and I know that UART0 works perfectly when I cut the traces and hook up my Sparkfun UART/USB. So there is clearly a difference in how UART0 is configured verses UART3.

Software

I have used this exact FTDI USB adapter on many projects and it always works great. Here's what I've tried to enable UART3 on the dev board:

TI Web-Based PinMux Configuration for AM335x (http://dev.ti.com/pinmux)

Yocto Kernel Serial Driver Selection

After wandering around the enormity of the default kernel serial 8250 stack, I eventually stumbled upon the omap-serial.c driver. I wanted to see if it would magically fix my problem or in the least, be less code to sift thru (being a single .c file).

So I configured the kernel (make menuconfig) to disable 8250 and enable CONFIG_SERIAL_OMAP found in Device Drivers->Char Drivers->Serial Drivers.

Yocto Kernel Device Tree Configuration

The TI Pinmux generates this code which I add to my Yocto environment's kernel device tree:

myuart3_pins_default: myuart3_pins_default {
    pinctrl-single,pins = <
        0x160 ( PIN_INPUT | MUX_MODE1 ) /* (C15) spi0_cs1.uart3_rxd */
        0x164 ( PIN_OUTPUT_PULLDOWN | MUX_MODE1 ) /* (C18) eCAP0_in_PWM0_out.uart3_txd */
    >;
};

I notice that when editing kernel-source/arch/arm/boot/dts/var-som-am33.dts there is a SPI device called spi1_pins_default which uses the 0x164 pin, so I remove its entry too (not shown in the git diff). SPI1 isn't used by default anyway, but I was just being paranoid.

Here is a git diff of my device tree source:

diff --git a/arch/arm/boot/dts/var-som-am33.dts b/arch/arm/boot/dts/var-som-am33.dts
index 0fdb4e3..05fbd0a 100644
--- a/arch/arm/boot/dts/var-som-am33.dts
+++ b/arch/arm/boot/dts/var-som-am33.dts
@@ -263,6 +263,13 @@
                >;
        };

+       myuart3_pins_default: myuart3_pins_default {
+               pinctrl-single,pins = <
+                       0x160 ( PIN_INPUT | MUX_MODE1 ) /* (C15) spi0_cs1.uart3_rxd */
+                       0x164 ( PIN_OUTPUT_PULLDOWN | MUX_MODE1 ) /* (C18) eCAP0_in_PWM0_out.uart3_txd */
+               >;
+       };
+

@@ -533,11 +522,8 @@
 };

 &uart3 {
-       /*
-       pinctrl-names = "default", "sleep";
-       pinctrl-0 = <&uart3_pins_default>;
-       pinctrl-1 = <&uart3_pins_sleep>;
-       */
+       pinctrl-names = "default";
+       pinctrl-0 = <&myuart3_pins_default>;
        status = "okay";
 };

Finally rebuild the kernel/device tree with bitbake:

yocto_varsomam33/tisdk/build $  MACHINE=varsomam33 bitbake -C compile linux-ti-variscite

Verify Device Tree Settings

Once the kernel and device tree have been built, boot them (in my case over TFTP/nfs-kernel-server) and check that our device tree settings are what we expect:

root@varsomam33:~# find /sys/firmware/devicetree/ -name "*myuart*"
/sys/firmware/devicetree/base/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/myuart3_pins_default
root@varsomam33:~# od -x /sys/firmware/devicetree/base/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/myuart3_pins_default/pinctrl-single,pins
0000000     0000    6001    0000    2900    0000    6401    0000    0100
0000020

If we endian-fix the output values (my busybox od tool doesn't support "od -t x1"), we see this:

PIN     |  VALUE
--------|-------
0x0160  | 0x0029
0x0164  | 0x0001

Which verifies precisely with the defines in include/dt-bindings/pinctrl/am33xx.h

#define PULL_DISABLE (1 << 3)
#define INPUT_EN     (1 << 5)

#define PIN_OUTPUT_PULLDOWN 0
#define MUX_MODE1   1

Hardware

Connections:

Carrier board           | Sparkfun USB
------------------------|-------------
J18 pin 9  (UART3_RXD)  | TXO
J18 pin 10 (UART3_TXD)  | RXI
J15 pin 4  (Ground)     | GND

Testing

I use a very simple 198-line serial terminal program written in C found here (http://github.com/bradgrissom/miniterm)

I have used it for years on various embedded linux and desktop linux devices. It does not use flow control as seen on line 123:

newsertio.c_cflag = cooked_baud | CS8 | CLOCAL | CREAD;

Next I'll open serial terminals on both my desktop linux machine with the Sparkfun device (/dev/ttyUSB1 in this case) and on the embedded side (/dev/ttyO3). I type characters into each terminal session. Notice the 'a' characters are received on the desktop when typed from the embedded session, but no characters are received on the embedded side when typed from the desktop session.

Embedded Serial Terminal

Output:

root@varsomam33:~# ./miniterm -d/dev/ttyO3
************ REMOTE CONSOLE: CTRL-] TO QUIT ********

Desktop Serial Terminal

Output:

# ./miniterm -d/dev/ttyUSB1
************ REMOTE CONSOLE: CTRL-] TO QUIT ********
aaa

Check UART Status

Notice we have transmitted some characters on UART3 but have not received any

root@varsomam33:~# cat /proc/tty/driver/OMAP-SERIAL
serinfo:1.0 driver revision:
0: uart:OMAP UART0 mmio:0x44E09000 irq:155 tx:3080 rx:8 RTS|CTS|DTR|DSR
1: uart:OMAP UART1 mmio:0x48022000 irq:156 tx:0 rx:0 DSR|CD|RI
2: uart:OMAP UART2 mmio:0x48024000 irq:157 tx:0 rx:0 CTS|DSR
3: uart:OMAP UART3 mmio:0x481A6000 irq:158 tx:3 rx:0 CTS|DSR
4: uart:OMAP UART4 mmio:0x481A8000 irq:159 tx:0 rx:0 CTS|DSR
5: uart:OMAP UART5 mmio:0x481AA000 irq:160 tx:0 rx:0 CTS|DSR

Saleae Logic Analyzer Screenshots

UART3 TX looks good between 0 and 3.3V

enter image description here

UART3 RX only drops to 2.5V from 3.3V

enter image description here

Concluding remarks:

Truth table from my testing so far. Note that when I say it doesn't work, it exhibits the problem described above (2.5V to 3.3V swing).

Board      |  UART   |  Configuration  |  Result
------------------------------------------------
Variscite  |  UART0  |  RS232 DCE      |  WORKS
Variscite  |  UART1  |  RS232 DTE      |  WORKS
Variscite  |  UART3  |  TTL/UART       |  NO WORK  (this is described in this post)
Custom     |  UART0  |  TTL/UART       |  WORKS
Custom     |  UART1  |  RS232 DTE      |  WORKS
Custom     |  UART1  |  TTL/UART       |  NO WORK  (used same procedure described in this post)

I feel like this has something to do with modem control lines (flow control) and that my configuration settings aren't being taken (as per /proc/tty/driver/OMAP-SERIAL)

Any help is appreciated, thanks!

Upvotes: 0

Views: 978

Answers (1)

Brad Grissom
Brad Grissom

Reputation: 3963

UART3 is being held high because it is also connected to a RS-485 chip's (LTC2852) pin 1. Luckily the board designers knew what they were doing and attached a 0 Ohm resistor (R83) on that line, so removing it frees up UART3's RX line.

As for UART1 on the custom board, the problem is that UART1 is connected on the SoM itself, to a WiFi/Bluetooth chip. This isn't obvious because Variscite doesn't release SoM schematics. They do, however, have a somewhat vague note in the carrier board schematics "Enable UART1 when on-SOM Bluetooth is not mounted".

On the carrier board, UART1 is connected to a SN74AVC4T245 bus transceiver which is turned on/off via a GPIO. The problem is that UART1 actually functions perfectly when interfaced with the bus transceiver. So testing on the dev carrier board, UART1 works perfectly and nobody is the wiser. Its only when you remove the bus transceiver that UART1 doesn't work.

In the end, my only conclusion is that the bus transceiver is tolerant to handling a logic level of 2.5V - 3.3V whereas ordinary UART devices are not.

Upvotes: 0

Related Questions