About UART talks to a drone

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hello,

I want TX2 to talk with a drone through UART directly, anyway, I got messy code all the time. The baud rate is 921600 (also tested with 115200). The test is under Ubuntu 16.04 with ROS (Kinetic): The serial port is "/dev/ttyTHS1(UART2).

We had built a system to talk to the drone through a USB adapter cable, which works fine, the same setup as above. The serial port is "/dev/ttyUSB0).

All the tests are implemented on both J130 (Auvidea) and Nvidia Develop Kit.

Thanks in advance!

Best Regards,
Tao Wang
Automodality Inc.

2

hello tao.wang,

could you share what’s the messy code you saw?
also, please check from the kernel driver side to confirm the baud rate was setting correctly.
please check the tegra_set_baudrate() function at below path,
thanks

kernel/kernel-4.4/drivers/tty/serial/serial-tegra.c
3

Thanks JerryChang,

The setting of baud rate should be of no problem, as I can set baud rate with “stty”, and also it works very well with USB-FTDI cable.

Here is the hexadecimal output of putty :
00000000: 3d7e 3d7e 3d7e 3d7e 3d7e 3d7e 3d7e 3d7e =~=~=~=~=~=~=~=~
00000010: 3d7e 3d7e 3d7e 3d20 5075 5454 5920 6c6f =~=~=~= PuTTY lo
00000020: 6720 3230 3138 2e30 312e 3239 2031 373a g 2018.01.29 17:
00000030: 3138 3a32 3420 3d7e 3d7e 3d7e 3d7e 3d7e 18:24 =~=~=~=~=~
00000040: 3d7e 3d7e 3d7e 3d7e 3d7e 3d7e 3d0d 0aff =~=~=~=~=~=~=…
00000050: a0f0 6357 00a5 00c8 6880 0000 0000 00ff …cW…h…
00000060: 0000 b77a 0000 8800 a7af 1fa5 0000 7f00 …z…
00000070: 007c fefb 0000 0000 4400 2370 00fe e39b .|…D.#p…
00000080: 0000 00cb 00df 0000 0000 4c00 8300 ec00 …L…
00000090: 3f6e 3feb b59f c6ff eb00 5094 00bf 0000 ?n?..P…
000000a0: c3ed 6100 361d 7b00 0000 81e6 ad00 e670 …a.6.{…p
000000b0: 3671 c6f7 bc25 4e9c bc37 0087 0000 b07f 6q…%N…7…
000000c0: ed8b 3900 f500 f300 fe8c e376 eb01 acce …9…v…
000000d0: 0000 3e00 0000 013d e100 0000 009e 2b87 …>…=…+.
000000e0: 0f80 0000 4bbd 0000 f69e f961 7c00 8861 …K…a|…a
000000f0: d300 0000 ecff 003f 0000 d868 00b9 5d00 …?..h…].
00000100: 1579 9b00 00db b000 0000 0000 7b00 0000 .y…{…
00000110: b800 fff8 eff9 00a6 0000 00dc 00f8 2fff …/.
00000120: 00f3 0000 2a9b 9eff 795f f97c 006e 00fc ……y_.|.n…
00000130: ff00 1900 843a de82 bf44 227f bef8 1dfc …:…D"…
00000140: eb00 c200 0000 2200 a459 0000 ffff 43fb …"…Y…C.
00000150: 009e 83e6 006b 9f00 0000 000a 00a8 459b …k…E.
00000160: 00a8 0000 01bb 0018 8e79 f800 8f00 00df …y…
00000170: 00e3 c378 006e 00fd ff00 00af 0cf8 90b7 …x.n…
00000180: 0000 46b4 263f 2f8e 6dfe ff83 0000 008b …F.&?/.m…
00000190: 9f00 0000 00c0 00bb fe00 6500 94d3 ff00 …e…
000001a0: 4e4c ff02 0000 0000 6a7f 2d00 2b00 7700 NL…j.-.+.w.
000001b0: a000 8f74 fa00 00fe 0000 81bf 0ca6 0000 …t…
000001c0: 188c db00 ff00 3d00 fc00 2cfe 00cd 6f00 …=…,…o.
000001d0: 4600 d800 bf00 0001 7300 a0c5 007f e300 F…s…
000001e0: fc00 0000 e733 1c00 00f9 0000 0072 0000 …3…r…
000001f0: 00c6 00d8 ceca fb00 ff00 0000 c079 0000 …y…
00000200: 00fa f7ad 0000 7f4d 2cfe bcfd 5bfa 9223 …M,…[…#
00000210: 0000 4968 8700 0000 8f3e 0000 0077 ffe2 …Ih…>…w…
00000220: 4050 007f 0000 0000 7046 5804 5b00 00fc @P…pFX.[…
00000230: 00ba 00a6 2e00 00ff 0000 d75f fac5 8200 ……
00000240: e842 003f 8900 a1b8 17fa f633 003f 0000 .B.?..3.?..
00000250: a500 faf3 3c00 00be 00fc 4600 6400 5f00 …<…F.d..
00000260: 006e c300 df0f 00dd c7f8 8800 fbfd fa00 .n…
00000270: 0000 0038 f87f 25bd f7ce 0000 00fd 00ff …8…%…
00000280: 3881 ea00 00f2 28a7 0081 0000 0088 00d3 8…(…
00000290: 00ca 000b 00bf 3f00 008d aa2a 000e ab00 …?..…
000002a0: 00fc 21cd 00fc af05 9b50 7554 5459 0000 …!..PuTTY…
000002b0: 1000 7d00 006e 00fb 7be4 7eb8 008b 278b …}…n…{.~…‘.
000002c0: 00fe 0000 a000 48e8 00d7 0000 0000 9c00 …H…
000002d0: 7a00 8767 92f9 006c e5f8 afe3 00b3 cf68 z…g…l…h
000002e0: fb00 8100 00af edff fe00 0a84 db77 d200 …w…
000002f0: 86f4 009f 0000 ebdf a800 0000 f500 0d00 …
00000300: 0000 4400 0000 fbc8 00a2 0008 d500 7d43 …D…}C
00000310: 00c8 00f4 0000 df00 1800 0016 bcc5 fefc …
00000320: 0000 90ae 9f00 b40f b088 c669 e12e 3600 …i…6.
00000330: 483f 8300 f2ff 008e 0000 7100 5e77 0300 H?..q.^w…
00000340: 891b bfe2 7f00 0098 fc00 a500 6d2f 8cb1 …m/…
00000350: ff00 970d 0000 00a7 035e 0000 0200 fced …^…
00000360: 0000 1200 e429 0000 0000 00da 0000 a2c3 …)…
00000370: 001b f2df 625c 0000 0063 00ff 0c00 dff8 …b.…c…
00000380: 00a6 003e cd59 6234 00fa 067a e300 fcbd …>.Yb4…z…
00000390: c37b 00f9 0000 9800 0000 00fe 009a d096 .{…
000003a0: 0000 1b71 cff7 c91c 9edd ad00 1c00 0000 …q…
000003b0: 7f3d 00f9 ffdf 0000 0001 0000 dcd1 0000 .=…
000003c0: 0000 2900 fd00 9084 0087 0700 0000 7dfd …)…}.
000003d0: dd86 9e00 fbc2 fd00 5c32 c8fc 0800 00b8 …\2…
000003e0: ff6d 87cf 7f00 00b6 c617 1500 fcd9 e24b .m…K
000003f0: 3f00 7700 8a00 0000 06c7 0000 f404 f600 ?.w…
00000400: e89b 00f7 e200 0000 4ad7 0000 ff7f 0000 …J…
00000410: 0000 47f0 0000 00d3 7900 00fb 64ec 000b …G…y…d…
00000420: a720 00ed 0000 c7d7 08fb 0000 a33f ff00 . …?..
00000430: f900 c000 ff00 b166 c8bf 0010 0000 0030 …f…0
00000440: ca75 a59d 7e00 e500 0000 4f0e 9000 10cb .u…~…O…
00000450: bf9e ff00 0000 0000 003f ef00 fe00 00f7 …?..
00000460: 8c00 1700 d2a7 00f5 7500 007b 002f fd00 …u…{./…
00000470: f8c6 6100 3cf0 00e3 fe00 01bd 15ef 8300 …a.<…
00000480: 00ab 9ecc 0000 dcce 0013 00ed 0000 0000 …
00000490: e725 00fe fb00 7e4c c400 0027 00d7 000b .%…~L…’…
000004a0: 0068 813d dd8e 0000 3720 006a b200 0002 .h.=…7 .j…
000004b0: df6c fcf9 7f00 a062 cfef 004f 7f00 cfc0 .l…b…O…
000004c0: 091f 006b f44d 2762 0a0c 0000 3d00 0000 …k.M’b…=…
000004d0: f60b ccff 00df f1aa 6453 14fd bcfc c100 …dS…
000004e0: e6a2 fe00 8efe 3e00 0000 0000 00fa 00ff …>…
000004f0: 1000 9300 f43b 00fe 00f5 900f 9600 8f00 …;…
00000500: 00db 0000 0000 01be ab00 fe63 3f64 b700 …c?d…
00000510: c100 5d00 00ce 6700 7c00 bf70 0000 fef7 …]…g.|…p…

4

Hello JerryChang,

My USB cable gets 0403:6001, which should be FT232B. With this cable (/dev/ttyUSB0), my TX2 can talk with my drone very well. Anyway, when my TX2 try talk with my drone through UART directly (DSK UART 1: /dev/ttyTHS2, J130 UART2: /dev/ttyTHS1), it fails. The data from the FCU is blocked or paged, but what I got from the direct UART seems has no block or page.

I have checked what you advised. I also checked the logic level (3.3V TTL) through oscilloscope, the waveform looks good. (Don’t know how to paste picture here.)

What will be in FT232B, which may get “better” communication than a direct UART?

Thanks!

5

hello tao.wang,

could you check TX2 TRM, you can access this from Jetson Download Center.
[url]https://developer.nvidia.com/embedded/downloads[/url]

please refer to [UNIVERSAL ASYNCHRONOUS RECEIVER/TRANSMITTER (UART)] chapter for more details.
thanks

6

You may need to enable hardware (CTS/RTS) flow control if buffers are the reason for failure (and at high speeds the odds of this occurring go up).

7

Thanks, linuxdev. We have just 3 wires connected (if required I would connect the hardware flow control wires), all the same configuration, the USB-cable works well while direct UART does not work. It seems not the problem of flow control. I am reading TX2 TRM as JerryChang recommended, there are two mode 16450 (no fifo) and 16550 (with fifo), in default it is 16450. I am trying to enable 16550, do you know how to do that? FCR is shared with IIR, IIR is read only and FCR is write only.

8

16450 is more or less compatibility…I doubt anyone should ever use this unless they have some need specific to the 16450. If it was in 16450 mode it would probably cause problems.

On the other hand, different UARTs have different buffer sizes. Hardware flow control may help at higher speeds, especially if one UART has a larger buffer than the other. It is probably worthwhile attaching the two extra wires for testing (just make sure they are shielded).

9

Thanks linuxdev. My FCU only supply for 3 pins out: TX, RX and ground.

In TRM for the FCR, what does it mean of two explanations for bits 7:6, as I understand these are bit 6 and 7. I confused here (Tegra2_TRM_DP05282012v02.pdf, page 753). More confused on page 735 of “16550 mode programming”: “Program FCR[0] to 1”.

UART FIFO Control and Interrupt Identification Registers

Offset: 008h | Read/Write: R/W | Reset: 0b00000000

Bit Reset Description
7:6 X EN_FIFO: FIFO Mode Status 0=16450 mode(no FIFO), 1 = 16550 mode (FIFO)
1 = MODE_16550
0 = MODE_16450
7:6 0x0 RX_TRIG: FIFO_COUNT_GREATER_12 deprecated
0 = FIFO_COUNT_GREATER_1
1 = FIFO_COUNT_GREATER_4
2 = FIFO_COUNT_GREATER_8
3 = FIFO_COUNT_GREATER_16
3 = FIFO_COUNT_GREATER_12

10

I try to read the UART register ($busybox devmem 0x3110008), the system will crash for every try. What is the problem?

Is there any reference for changing UART mode from 16450 to 16550?

11

I don’t know if this is the case, but if a component is in a power saving mode or locked by something else (e.g., a GPIO being used as some other function or a controller’s power not enabled in device tree), then you will get errors.

Generally speaking, each UART belongs to a controller which is listed with a base address in the TRM (Table 2). Once you identify the controller the addresses you see are relative to that base address. Probably the first step is to be sure you are looking at the correct controller base address.

Another place where sometimes addresses fail is if you cross virtual and physical addresses. The address maps you see for physical hardware should be physical address, but there may be cases of memory controller translation (I don’t know if this is an issue, it’s just something to be careful with).

If you know you have the right address you should start by checking if some other purpose has been defined and set. The device tree may give clues for that. Extract what is currently used:

dtc -I fs -O dts -o extracted.dts /proc/device-tree

Look at all of the entries “serial@3110”. Because of offsets you won’t see “3110008”, you’ll only see “3110000”. In the TRM address map this shows:

UARTB  0x03110000 ...

In an extracted R28.1 TX2 device tree:

serial@3110000

Device tree is probably the place to make changes for testing.

One thing I notice is that the base address table and other documentation may list a different number of digits. In all cases actual bytes require two hex digits per byte. Compare when adding a bit of a “ruler” to show number of bytes:

.         serial@31 10 00 0
busybox devmem 0x31 10 00 8
byte             11 22 33 4
...try instead with 08 appended instead of 8 appended...
<b>busybox devmem 0x311000<u>08</u></b>
                 11223344

Someone from NVIDIA will need to comment on whether 0x31100008 is correct instead of 0x3110008. Or trial and error, see if this works for you. If this is the case, then the extracted device tree address seems a bit odd so I could be wrong about that and 0x31100008 may just be something else which allows reading memory.

12

Thanks linuxdev,

I tried 0x31100008, and got all 0. Also for 0x31100000, 0c, 10, all got zero. There is maybe different mapping between this address. I tried again on 0x3110008 (just reading), still cause the system restart.

Yesterday and today, I make the communication built @115200 and @230400 (baud rate) sometime on SDK UART1 (tty/THS2), however failed @921600 and @38400. On oscilloscope, @921600 baud rate, there is big oscillation at rising and falling edge of TX (from TX2).

On Auvidea J130 success just once @230400, and failed all other time @230400 and other rates.

Do you know how to change UART mode 16450 (default, seems no FIFO) to 16550 in dts file or other way?

extraced.txt (354 KB)

IMG_20180203_114837159.jpg
IMG_20180203_114837159.jpg4160×2340 2.99 MB

IMG_20180203_114837159.jpg
IMG_20180203_114837159.jpg2080×1170 942 KB

13

It might be of use to examine your device tree when unmodified (I’ve never seen a J130). If possible can you extract this tree from a non-modified J130 and post it? You could do this:

dtc -I fs -O dts -o extracted_dts.txt /proc/device-tree

The reason I used the “.txt” on the end is so you can attach it to an existing post in the thread without the forum software saying “no”. If you hover your mouse over the upper right corner of one of your existing posts where the icon is for quoting you will see additional icons show up. One of them is a paper clip. You should be able to attach it that way.

14

It is appreciated, linuxdev, you are with me with my problem. Now I know how to attach some files.

I also attached a oscilloscope picture of the TX from TX2, there is big overshoot on both rising and falling edge.

I found a “serial-tegra.c” file in JetPack (LT3.1), there is a function to write FCR, so there is a way to change the UART mode (or write register of UART), which need not to write to the Memory IO.

I want to attach in this response, but after I edit it, the attachment is gone. So I attached in the last response I made.

J130 is just a carrier like the developer kit. I use the same TX2 for both J130 and DSK. So the kernel image is the same (as the kernel is in the flash of TX2, not on the carrier).

15

A few minutes ago I saw the attachments briefly, and got the device tree. Then as you mentioned, it disappeared. I do see it in the previous post though.

Some information to put out there, not necessarily with any specific meaning…

The device tree for “serial@3100000”, with one exception, is an exact match on your J130 versus the dev board. The phandle lines are slightly different.

The “reg” entry is identical. These are for register setup. I’d have to dig in to see the meaning of individual entries, but the implication is that unless something else altered the UART at a later time, then that UART is operating in 16550 mode because this is also the mode of this controller on the dev board.

This of course doesn’t rule out something else trying to use the port, and is complicated since the UART has both a regular ttyS# driver and the DMA version using ttyTHS# (and it would be bad to use both drivers at the same time…you’ll see the “compatible” line has two possibilities, but it doesn’t say which one is chosen at any given moment).

I don’t know if the that leading edge is purely a spike or if it is ringing. If your oscilloscope is fast enough (“expensive”) you can zoom in on one of the spikes and know if it is from AC coupling or from something else. Whether or not it would matter I don’t know…it would depend when the UART samples (it probably isn’t possible to show the relevant clock next to this…this is probably in an inaccessible part of the silicon). As a percentage of the total waveform the spike does look fairly extreme. The oscilloscope quality itself can have an effect on this. As the signal speed goes up it’ll become more important relative to the clock determining when to sample occurs.

If you have a reference clock (square wave you know is sharp and well-formed) at about the same frequency as that signal (or at minimum a very sharp rising/falling edge), then you might put your scope on that and adjust the compensation (assuming the probes have that…one of the reasons why some probes are more expensive than others). The goal is of course to know whether the ringing is actually part of the circuit or if it is part of the measurement.

What quality is the wiring with the serial signal? Is it twisted pair? Is it shielded? Are there multiple pairs in a single cable? FYI, one thing I usually suggest if current cable has issues is to use ethernet cable for testing…individual pairs have different twist pitches and there is a shield.

16

“serial@3100000” is the tty console “/dev/ttyS0”.
“serial@3110000” is for UART2 “/dev/ttyTHS1” (I use it on J130)
“serial@c280000” is for UART1 “/dev/ttyTHS2” (I use it on SDK)

For UART2(3110000) and UART1(c280000), as in dts file, only one in “compatible”. How can we verify it is 16550 mode? And how we know the size of the FIFO?

For the device tree I attached is the same on dev board and J130, as I use the same TX2: I do the labor to unplug and plug, the hard part is the fan connector, lol.

Here is the output of dmesg:

nvidia@tegra-ubuntu:~/tmp$ dmesg | grep tty
[ 0.000000] Kernel command line: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 memtype=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x03100000 nvdumper_reserved=0x2772e0000 gpt tegraid=18.1.2.0.0 tegra_keep_boot_clocks maxcpus=6 androidboot.serialno=0321917026104 bl_prof_dataptr=0x10000@0x277240000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
[ 0.014522] console [tty0] enabled
[ 0.475591] console [ttyS0] disabled
[ 0.475643] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 37, base_baud = 25500000) is a Tegra
[ 2.568765] console [ttyS0] enabled
[ 2.570671] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 38, base_baud = 0) is a TEGRA_UART
[ 2.571801] c280000.serial: ttyTHS2 at MMIO 0xc280000 (irq = 39, base_baud = 0) is a TEGRA_UART
[ 2.572905] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 40, base_baud = 0) is a TEGRA_UART
[ 12.890387] systemd[1]: Created slice system-serial\x2dgetty.slice.

Output of setserial:

nvidia@tegra-ubuntu:~$ setserial -g /dev/ttyTHS2
/dev/ttyTHS2, UART: undefined, Port: 0x0000, IRQ: 39
nvidia@tegra-ubuntu:~$ setserial -g /dev/ttyS0
/dev/ttyS0, UART: undefined, Port: 0x0000, IRQ: 37
nvidia@tegra-ubuntu:~$ setserial -g /dev/ttyTHS1
/dev/ttyTHS1, UART: undefined, Port: 0x0000, IRQ: 38

Output of stty:

nvidia@tegra-ubuntu:~$ stty -F /dev/ttyTHS1 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

My colleague just made a twisted and shielded cable, will let you know what is going on.

Test on the dev board, the same. TX from oscilloscope looks better with smaller overshoot on the edges (see the attachment).

IMG_20180203_175310634.jpg
IMG_20180203_175310634.jpg4160×2340 1.85 MB

IMG_20180203_175310634.jpg
IMG_20180203_175310634.jpg4160×2340 1.85 MB

17

Normally I’d just use setserial or stty to find out, but this isn’t set up to properly ID the UART type on the Jetson. FYI, this is probably something the driver needs to have added. I suspect that all of these default device trees use 16550 mode, but I can’t guarantee it.

What I see in the Parker TRM (38.4.3) shows the bring-up to use FCR[0] as “1” when in 16550 mode, or “0” when in 16450 mode. Basically it says the 16450 mode doesn’t use the FIFO queues, but 16550 does. Other bits seem to also be involved, but if not in FIFO mode it is safe to say it probably isn’t 16550. Here is an excerpt of the TRM 38.4.2 (16450) and 38.4.3 (16550) start procedures side-by-side, with some "diff"s pointed out (using strikethrough characters when instructions match…ascii art might be ugly it isn’t fixed width font):

  • 38.4.2 16450 Mode Programming......................................38.4.3 16550 Mode Programming
  • 1. Program pinmux settings to select a UART....................1. Program pinmux settings to select a UART
  • 2. Enable the UART clocks...................................................2. Enable the UART clocks
  • 3. For enabling internal loopback, program MCR[4] to 1...3. For enabling internal loopback, program MCR[4] to 1
  • 4. Program FCR[0] to 0.........................................................4. Program FCR[0] to 1
  • ...............................................................................................5. Program trigger levels as required
  • 5. Enable interrupts in the IER register as needed.............6. Enable interrupts in the IER register as needed
  • 6. Write data into the THR register.......................................7. Write data into the THR register
  • 7. Wait for a THR interrupt, if enabled, or poll for LSR[5]...8. Wait for a THR interrupt, if enabled, or poll for LSR[5]
  • 8. During a receive, wait for an RDR interrupt or poll for LSR[0]/LSR[9]..9. During a receive, wait for an RDR interrupt or poll for LSR[0]/LSR[9]
  • 9. Read the UART.LSR register to clear interrupts..............10. Read the UART.LSR register to clear interrupts[/.]
  • 16550 only:
  • 11. APB-DMA requester numbers for UARTs A, B, C, and D are 8, 9, 10, and 19, respectively
  • 12. UART instanced to GPCDMA mapping:
  • 13. LSIO instances: - UART1/A – 8 - UART2/B – 9 - UART4/D-19 - UART5/E- 20 - UART6/F- 12
  • 14. AON UART instances: - UART3/C – 3 - UART7/G – 2

Notice one step is in italics because reading the register will clear interrupts. The act of reading it might cause problems. Further steps are listed in the TRM related to various options.

This may be of interest…I am able to get both devmem2 and busybox devmem to work at 0x3100008 (this is on the TX2 dev board, but likely it is the same on the J130):

root@x2:~# busybox devmem 0x3100008
0x000000C1
root@x2:~# devmem2 0x3100008
/dev/mem opened.
Memory mapped at address 0x7f87ce6000.
Value at address 0x3100008 (0x7f87ce6008): 0xC1

In binary 0xC1 is “0b11000001”. I’m not sure which is the FCR[1] (FIFO Control Register) offset. One really important point I did see though is that the FCR is write-only. It isn’t useful nor is it possible to detect 16550 mode by means of this register. The 0x8 offset though seems to be working, at least on 0x3100008.

Look in the TRM “UART FIFO Control and Interrupt Identification Registers” section 38.9.3 for the 0x8 bit meanings. Here are my excerpt notes on the 0xC1 (“0b11000001”) meaning:

8 7 6 5 4 3 2 1
1 1 0 0 0 0 0 1
              \- FIFOs enabled
  | |
  \------------- bits 6 and 7 work together
                 - 01 would be 16450 mode, 10 would be 16550 mode.
                 - this case is 16550 since it is 10 going from bits 7:6.
18

On the new image it looks much better, but there may still be ring to worry about…I have no way to know if that much ring is tolerable or not. if your scope has a fast enough sample rate you may want to magnify a single square way and see if it rings all the way across or if it is just noise.

19

I also can read and write 0x3100008 (0x3100000, 0x310000c, 0x3100010). The problem that cause system restart is to read or write 0x3110008. This is UART0, which is used as tty console in Ubuntu. Anytime I try to operate on this UART0 will crash the system.

For the FIFO controller, in TRM it is not consistent: you mentioned about 38.4.3, but also check 38.9.3 where offset and bits definition are put. Enable the FIFO doesn’t mean the mode, am I right?

Last time you mentioned “compatible” section in dts file of serial@0x3100000, i.e. [compatible = “nvidia,tegra20-uart”, “nvidia,tegra186-hsuart”;]. what is the difference of tegra20-uart and tegra186-hsuart? As the other UARTs including 0x31100000 and 0xc280000, they only have tegra186-uart, how will it be if I change it to tegra20-uart?

What is the difference of tegra20-uart and tegra186-uart?

Now at baud rate of 230400 and 115200, it works. So it should be the setting of FIFO or buffer.

20

Yes, 0x3100008 works, but 0x3110008 crashes. I have been wondering if this is due to the difference between using the DMA driver (“/dev/ttyTHS#”) versus the regular non-DMA driver (“/dev/ttyS#”).

Here is a kernel OOPS from reading the UART controller register at 0x3110008 (there is no error with read of 0x3110008):

[  171.690648] CPU3: SError detected, daif=1c0, spsr=0x800000c5, mpidr=80000101, esr=bf40c000
[  171.690662] CPU5: SError detected, daif=1c0, spsr=0x800000c5, mpidr=80000103, esr=bf40c000
[  171.690675] CPU0: SError detected, daif=1c0, spsr=0x800000c5, mpidr=80000100, esr=bf40c000
[  171.690724] CPU4: SError detected, daif=140, spsr=0x40000145, mpidr=80000102, esr=bf40c000
[  171.690798] CPU2: SError detected, daif=1c0, spsr=0x800000c5, mpidr=80000001, esr=be000000
[  171.690829] CPU1: SError detected, daif=1c0, spsr=0x800000c5, mpidr=80000000, esr=be000000
[  171.690837] **************************************
[  171.690851] CPU5 Machine check error in AXI2APB@0x2390000:
[  171.690868] Raw FIFO Entry: 0
[  171.690873]  ADDR: 0x43110008
[  171.690878]  STAT: 0x1868241
[  171.690883] --------------------------------------
[  171.690889] Decoded FIFO Entry: 0
[  171.690894]  Direction: READ
[  171.690899]  Bridge ID: 0x1
[  171.690906]  Error Type: 0x12 -- Timeout error
[  171.690910]  Length: 0
[  171.690920]  Protection: 0x2 -- Unprivileged, Non-Secure, Data Access
[  171.690927]  Source ID: 0x1 -- CCPLEX
[  171.690936]  AXI_ID: 0x6 -- A57 Core 2
[  171.690942]  Cache: 0x0 -- Strongly Ordered
[  171.690947]  Burst: 0x1
[  171.691033] <b> Address: 0x3110008 -- /serial@3110000 + 0x8</b>
[  171.691038] **************************************
[  171.691957] ROC:IOB Machine Check Error:
[  171.691977]  Address Type = Secure DRAM
[  171.692086]  Address = 0x0 (Unknown Device)
[  171.692545] Bad mode in Error handler detected, code 0xbf40c000 -- SError
[  171.692559] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[  171.692598] Modules linked in: fuse bcmdhd pci_tegra bluedroid_pm
[  171.692620] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.4.38-tegra #1
[  171.692625] Hardware name: quill (DT)
[  171.692634] task: ffffffc1ececbe80 ti: ffffffc1ecee4000 task.ti: ffffffc1ecee4000
[  171.692676] PC is at t18x_a57_enter_state+0x48/0xc4
[  171.692687] LR is at t18x_a57_enter_state+0x20/0xc4
[  171.692695] pc : [<ffffffc0009116b4>] lr : [<ffffffc00091168c>] pstate: 800000c5
[  171.692700] sp : ffffffc1ecee7ec0
[  171.692712] x29: ffffffc1ecee7ec0 x28: ffffffc1ecee4000 
[  171.692724] x27: ffffffc000b37f00 x26: 0000002807bf735e 
[  171.692734] x25: ffffffc0013a1000 x24: 0000000000000000 
[  171.692745] x23: ffffffc00132bfc8 x22: ffffffc00132bfe0 
[  171.692754] x21: ffffffc0013a17c8 x20: ffffffc00146a630 
[  171.692763] x19: 0000000000000000 x18: 0000000000000000 
[  171.692773] x17: 0000007fa4bfc988 x16: ffffffc0001d6f9c 
[  171.692783] x15: 00000000b504f333 x14: 0000000000005abd 
[  171.692792] x13: 00000000b504f333 x12: 0000000000000000 
[  171.692802] x11: 0000000000000400 x10: 00000000000008a0 
[  171.692812] x9 : 00000000ffff82df x8 : ffffffc1ececc780 
[  171.692821] x7 : 00000027f8f8a580 x6 : 000000000000bf12 
[  171.692830] x5 : 0000000000000000 x4 : 00ffffffffffffff 
[  171.692839] x3 : 000000003b9aca00 x2 : 0000000000f42710 
[  171.692848] x1 : 0000000000000000 x0 : 0000000000000000 
[  171.692850] 
[  171.692860] Process swapper/5 (pid: 0, stack limit = 0xffffffc1ecee4020)
[  171.692865] Call trace:
[  171.692879] [<ffffffc0009116b4>] t18x_a57_enter_state+0x48/0xc4
[  171.692906] [<ffffffc0007d8194>] cpuidle_enter_state+0x88/0x2dc
[  171.692917] [<ffffffc0007d8420>] cpuidle_enter+0x18/0x20
[  171.692940] [<ffffffc0000e7a74>] call_cpuidle+0x28/0x50
[  171.692952] [<ffffffc0000e7c18>] cpu_startup_entry+0x17c/0x340
[  171.692970] [<ffffffc00008ede8>] secondary_start_kernel+0x12c/0x164
[  171.692979] [<000000008008192c>] 0x8008192c
[  171.692994] ---[ end trace 2f8504c7d2596ade ]---
[  171.698314] Kernel panic - not syncing: Attempted to kill the idle task!
[  171.698327] CPU0: stopping
[  171.698340] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G      D         4.4.38-tegra #1
[  171.698344] Hardware name: quill (DT)
[  171.698347] Call trace:
[  171.698366] [<ffffffc000089854>] dump_backtrace+0x0/0x100
[  171.698378] [<ffffffc000089a1c>] show_stack+0x14/0x1c
[  171.698392] [<ffffffc0003136f8>] dump_stack+0x98/0xc0
[  171.698401] [<ffffffc00008f40c>] handle_IPI+0x300/0x30c
[  171.698409] [<ffffffc00008161c>] gic_handle_irq+0x9c/0xb4
[  171.698417] [<ffffffc000084740>] el1_irq+0x80/0xf8
[  171.698427] [<ffffffc0007d8420>] cpuidle_enter+0x18/0x20
[  171.698435] [<ffffffc0000e7a74>] call_cpuidle+0x28/0x50
[  171.698441] [<ffffffc0000e7c18>] cpu_startup_entry+0x17c/0x340
[  171.698455] [<ffffffc000b279fc>] rest_init+0x84/0x8c
[  171.698470] [<ffffffc0010cd97c>] start_kernel+0x39c/0x3b0
[  171.698475] [<0000000080b2e000>] 0x80b2e000
[  171.698481] CPU4: stopping
[  171.698491] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G      D         4.4.38-tegra #1
[  171.698495] Hardware name: quill (DT)
[  171.698497] Call trace:
[  171.698511] [<ffffffc000089854>] dump_backtrace+0x0/0x100
[  171.698521] [<ffffffc000089a1c>] show_stack+0x14/0x1c
[  171.698530] [<ffffffc0003136f8>] dump_stack+0x98/0xc0
[  171.698537] [<ffffffc00008f40c>] handle_IPI+0x300/0x30c
[  171.698543] [<ffffffc00008161c>] gic_handle_irq+0x9c/0xb4
[  171.698550] [<ffffffc000084740>] el1_irq+0x80/0xf8
[  171.698558] [<ffffffc0007d8420>] cpuidle_enter+0x18/0x20
[  171.698565] [<ffffffc0000e7a74>] call_cpuidle+0x28/0x50
[  171.698571] [<ffffffc0000e7c18>] cpu_startup_entry+0x17c/0x340
[  171.698578] [<ffffffc00008ede8>] secondary_start_kernel+0x12c/0x164
[  171.698583] [<000000008008192c>] 0x8008192c
[  171.698611] CPU2: stopping
[  171.698645] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D         4.4.38-tegra #1
[  171.698654] Hardware name: quill (DT)
[  171.698665] Call trace:
[  171.698810] [<ffffffc000089854>] dump_backtrace+0x0/0x100
[  171.698836] [<ffffffc000089a1c>] show_stack+0x14/0x1c
[  171.698859] [<ffffffc0003136f8>] dump_stack+0x98/0xc0
[  171.698880] [<ffffffc00008f40c>] handle_IPI+0x300/0x30c
[  171.698898] [<ffffffc00008161c>] gic_handle_irq+0x9c/0xb4
[  171.698916] [<ffffffc000084740>] el1_irq+0x80/0xf8
[  171.698943] [<ffffffc0007d8420>] cpuidle_enter+0x18/0x20
[  171.698967] [<ffffffc0000e7a74>] call_cpuidle+0x28/0x50
[  171.699003] [<ffffffc0000e7c18>] cpu_startup_entry+0x17c/0x340
[  171.699023] [<ffffffc00008ede8>] secondary_start_kernel+0x12c/0x164
[  171.699038] [<000000008008192c>] 0x8008192c
[  171.699060] CPU1: stopping
[  171.699085] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D         4.4.38-tegra #1
[  171.699096] Hardware name: quill (DT)
[  171.699105] Call trace:
[  171.699136] [<ffffffc000089854>] dump_backtrace+0x0/0x100
[  171.699158] [<ffffffc000089a1c>] show_stack+0x14/0x1c
[  171.699175] [<ffffffc0003136f8>] dump_stack+0x98/0xc0
[  171.699195] [<ffffffc00008f40c>] handle_IPI+0x300/0x30c
[  171.699210] [<ffffffc00008161c>] gic_handle_irq+0x9c/0xb4
[  171.699326] [<ffffffc000084740>] el1_irq+0x80/0xf8
[  171.699345] [<ffffffc0007d8420>] cpuidle_enter+0x18/0x20
[  171.699361] [<ffffffc0000e7a74>] call_cpuidle+0x28/0x50
[  171.699377] [<ffffffc0000e7c18>] cpu_startup_entry+0x17c/0x340
[  171.699394] [<ffffffc00008ede8>] secondary_start_kernel+0x12c/0x164
[  171.699407] [<000000008008192c>] 0x8008192c
[  172.320081] CPU3: stopping
[  172.322800] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G      D         4.4.38-tegra #1
[  172.330454] Hardware name: quill (DT)
[  172.334118] Call trace:
[  172.336577] [<ffffffc000089854>] dump_backtrace+0x0/0x100
[  172.341980] [<ffffffc000089a1c>] show_stack+0x14/0x1c
[  172.347034] [<ffffffc0003136f8>] dump_stack+0x98/0xc0
[  172.352087] [<ffffffc00008f40c>] handle_IPI+0x300/0x30c
[  172.357313] [<ffffffc00008161c>] gic_handle_irq+0x9c/0xb4
[  172.362712] [<ffffffc000084740>] el1_irq+0x80/0xf8
[  172.367509] [<ffffffc0000a8e28>] irq_exit+0x84/0xdc
[  172.372391] [<ffffffc0000f45e4>] __handle_domain_irq+0x6c/0xb4
[  172.378222] [<ffffffc0000815dc>] gic_handle_irq+0x5c/0xb4
[  172.383620] [<ffffffc000084740>] el1_irq+0x80/0xf8
[  172.388416] [<ffffffc0007d8420>] cpuidle_enter+0x18/0x20
[  172.393729] [<ffffffc0000e7a74>] call_cpuidle+0x28/0x50
[  172.398953] [<ffffffc0000e7c18>] cpu_startup_entry+0x17c/0x340
[  172.404787] [<ffffffc00008ede8>] secondary_start_kernel+0x12c/0x164
[  172.411050] [<000000008008192c>] 0x8008192c
[  172.438750] Rebooting in 5 seconds..[0000.271] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-mobile-2c57a56c)

This controller identifies in the device tree of my R28.1 dev board as:

compatible = "nvidia,tegra186-hsuart";
...
serial1 = "/serial@3110000";

…this is pure DMA/ttyTHS driver.

The controller which allows reading 0x8 offset byte:

compatible = "nvidia,tegra20-uart", "nvidia,tegra186-hsuart";
...
stdout-path = "/serial@3100000";
...
serial0 = "/serial@3100000";

…this is used as serial console and is in the non-DMA driver.

Can someone suggest if the DMA-capable driver may cause some sort of failure when trying to directly read the controller base address plus 0x8 offset? Versus working in the non-DMA version? My thought is that reading the controller registers should be uniform and repeatable across all serial UARTs which are powered up and set up via the device tree…but in this case this is not working.