Tool/software: Linux
FYI I have formatted my post in markdown and it looks best in a mono-spaced font.
I have a - Variscite VAR-SOM-AM33 SoM and dev board (VAR-AM33CustomBoard) and I'm trying to get UART3 to work with a - Sparkfun FTDI Basic Breakout - 3.3V TTL UART to USB adapter (http://sfe.io/p9873) **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) -------------------------------------------- - UART3 with RXD and TXD only - UART pins - C15 is RXD, No Pull (unlike UART0 by the way) - C18 is TXD, Pull Down (just like UART0 by the way) 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 (github.com/.../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 ------------------------ - I type three 'a' characters on the embedded terminal. - I do not receive any characters typed from the desktop terminal Output: root@varsomam33:~# ./miniterm -d/dev/ttyO3 ************ REMOTE CONSOLE: CTRL-] TO QUIT ******** Desktop Serial Terminal ----------------------- - Notice I recieve the three 'a' characters on the desktop. - I type 't' in this terminal but it does not show up on the embedded 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 -------------------------------------- UART3 RX only drops to 2.5V from 3.3V ------------------------------------- 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!
