imx6ull uart receive

[Oman]

In the imx6ull platform, the serial port encounters abnormal data reception. The  description is as follows:

Problem Description:

If the external device is connected to the imx6ull serial port, it will emit a noise that low level when it sleeps,The waveform is a low level, about 40 ~ 50us.The baud rate of communication is 9600bps, 8n1

Read serial port data for a long time in imx6ull application layer, and receive data of 0xff all the time.

Q1. After calculating 9600 baud rate, the start bit time is 104us, while the time of 40 ~ 50us should not be recognized as the beginning of a data by the serial controller. Why can we receive the binary data of 0xff?

Q2. After testing, it is found that if the external device is disconnected, the application program can still read the secondary data of 0xff. Why can the data still be read after the device is disconnected?

this question happend at EVB board,I think it's the linux driver that causes this problem.

All IMX platform should all have it.

You can use GPIO port to simulate TX for testing

[Oman]

There are still problems in reading from the real Rx line.

I think the problem is linux drivers for uart or hardware of chip,not the app settings or other.

[BiyongSUN]

Double confirm right config the tty, ex: is using stty to disable the echo. 

stty -F /dev/ttymxc2  -echo

[Oman]

Hi Biyong,

I have done test,and added your said.But the problem is still exist.

Showing settings:

#stty -F /dev/ttymxc3

speed 9600 baud; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
ignbrk -brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Should it have taken effected?

I added some log in kernel driver code.To print the value of registers.

[ 1341.230883] dma_rx_callback, count=4096 ## urxd:80ff 80:d0d, 84:4027, 88:704, 8c:4042, 90:b10, 94:2010, 98:408d, 9c:2b, a0:0, a4:29, a8:c34, ac:4, b0:2ca4, b4:40, b8:0,

80,84,88 ... is offset of register.And the after number is its value.

So we can not see uart controller have reported errors,but the count is 4096.

I disconnected RX line, it still print.

[BiyongSUN]

How is loopback test?

[Oman]

Execute command line at the other terminal:

minicom -w -H -D /dev/ttymxc3 -b 9600

[BiyongSUN]

/unit_tests/UART/mxc_uart_stress_test.out

Usage:

        ./mxc_uart_stress_test.out <PORT> <BAUDRATE> <F> <R/W/L/D> <X> <Y> <O>

<PORT>: like /dev/ttymxc4

<BAUDRATE>: the baud rate number value (0~4000000)

<F>: enable flow control; other chars: disable flow control

<R/W/L/D>: R: read test; W: write test; L:loopback test; full duplex test

<X> : the group number: >= 1

<Y> : the group size: 1 - 1000

<O> : print log; other chars: disable log

[Oman]

Hi BiyongSun,

Because I don't know much about the working principle of thatprogram for mxc_uart_stress_test.out , can my above tests see where my main question is?

[BiyongSUN]

if you read the code of mxc_uart_stress_test.out(mxc_uart_stress_test.c), all the APIs, including header are only Linux layer. that is why I told you. It is not a special program. If you know about the Linux program, you can read the code. and understand the usage.

[BiyongSUN]

The mxc_uart_stress_test.out is standard program coding follow the Linux standard. not a special program. 

./mxc_uart_stress_test.out /dev/ttymxc2  115200

---- Running < ./mxc_uart_stress_test.out > test ----

Serial port /dev/ttymxc2 opened
NOT Using flow control
Speed set to 115200

write done : total : 200
         write : 10 calls issued, 20 bytes per call
:)[ 1 ] READ is good., count : 20
:)[ 2 ] READ is good., count : 20
:)[ 3 ] READ is good., count : 20
:)[ 4 ] READ is good., count : 20
:)[ 5 ] READ is good., count : 20
:)[ 6 ] READ is good., count : 20
:)[ 7 ] READ is good., count : 20
:)[ 8 ] READ is good., count : 20
:)[ 9 ] READ is good., count : 20
:)[ 10 ] READ is good., count : 20

read done : total : 200
         read : 10 calls issued, 20 bytes per call

----  Test < ./mxc_uart_stress_test.out > ended  ----

[BiyongSUN]

sorry. forgot to give you the command line

/unit_tests/UART/mxc_uart_stress_test.out /dev/ttymxc2  115200 D L 10 20 O

[Oman]

@BiyongSUN ,

How to verify next?

Do you have any suggestions? 

[BiyongSUN]

The internal loop already shows i.MX has no problem.

It probably has hardware connections issue. 

you can ask your hardware engineer to help you rework and test the external loop back to double confirm the issue.

[Oman]

Yes, the external terminal device sends a noise signal to 6ull, but it is recognized as valid data by 6ull, and always reports 0xff. My question is, can 6ull not be recognized as valid data?

[BiyongSUN]

have you even set the Parity  like stty parenb, parodd does, which will pass to the i.MX6ULL?

[BiyongSUN]

have you even used stty  to get the uart settings you are currently using?

[Oman]

Current settings:

#stty -F /dev/ttymxc3

speed 9600 baud; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
ignbrk -brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

[Oman]

I didn't set it.

[Oman]

Dear @BiyongSUN :

Well,I tested. And the execute results are attached.

According to the results, the loopback test is good. but  there are still problems in reading from the real Rx line.

[Oman]

I try to test, follow result:

root@imx6ull14x14evk:~# /unit_tests/mxc_uart_test.out /dev/ttymxc3 9600 A L 10 10 O
Test: MXC UART!
Usage: mxc_uart_test <UART device name, opens UART2 if no dev name is specified>
/dev/ttymxc3 opened
Attributes set
Test: IOCTL Set
Data Written= Test
Data Read back= Test

I don't seem to know how to use it. I'll try.

[jamesbone]

Unfortunately if the external device connected to the i.Mx6ULL UART,  it is taking Down the level of the signal for more than 40us that´s more than enough to validate in the UART mechanism that an Start bit it is available there is no option to remove this mechanism, or configure it.

I recommend if the external device can be attach through another component as glue logic,  let´s said a buffer or any other device like a transistor to avoid this low level.

Have a happy new year