Communication between two serial ports with Linux

Question

I hope someone can help me. I am trying to make a serial ports comunication in an ARM (I am working with Linux). The thing is that I am using program called terminal in windows which I use for see the output.

I have two cable connected from my ARM to the USB of my computer. What I do is open two windows of terminal program, and I connect with the respectives serial port, until here everything ok.

Now in one of the windows I have the ARM console (this is the ttymxc1 serial port) in which I write for example "echo hello > /dev/ttymxc2" (the ttymxc2 is the other port in the other windows). When I executed it somenthing appear, somenthing like this : "<0><0><0><0><0><0><0>". I was reading and I found out that it usually is a baud rate problem, so I change the baud rate of the "ttymxc2" to 115200 like the "ttymxc1" both with the same speed. Once I did that and I tried to send again the same echo, appear this: <0>©::*ë<0> so, somenthig was changing.

I get all the params of both serial ports and it is the output:

stty -a -F /dev/ttymxc1    

speed 115200 baud;stty: /dev/ttymxc1
line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ^J;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
 -parenb -parodd 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     


stty -F /dev/ttymxc2 115200    

stty -a -F /dev/ttymxc2    

speed 115200 baud;stty: /dev/ttymxc2
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 = 0;
-parenb -parodd 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    

And I do not have idea that which param can be changed, I am using in the terminal program the 115200 8n1 no Handshaking configuration in both windows.

Also when I execute this

setserial /dev/ttymxc2 -v autoconfig

/dev/ttymxc2, UART: undefined, Port: 0x0000, IRQ: 60

and

setserial /dev/ttymxc0 -v autoconfig

/dev/ttymxc0, UART: undefined, Port: 0x0000, IRQ: 58

So I was investigated and I red that I have to set somenthing like this:

setserial /dev/ttymxc2 uart 16550A

and this is the output:

setserial: can't set serial info: Invalid argument

But I am not sure that this is the problem, because the ttymxc1 port is also undefined and I can see the ARM output very nice, so I am very loss and I hope somen can help me.

I hope that the explanation be clear

Thank you very much

Output of dmesg | grep tty:

Kernel command line: noinitrd loglevel=7 no_console_suspend console=ttymxc1,115200 
fec_mac=00:05:51:07:B3:B5 mtdparts=gpmi-          nand:512k(NBoot)ro,2m(UBoot)ro,256k(UBootEnv),256k
(UserDef),6m(Kernel)ro,-(TargetFS) gpmi_debug_init enable_wait_mode=off   ubi.mtd=TargetFS root=ubi0:rootfs rootfstype=ubifs rootwait rw
bootconsole [ttymxc1] enabled
imx-uart.0: ttymxc0 at MMIO 0x2020000 (irq = 58) is a IMX
imx-uart.1: ttymxc1 at MMIO 0x21e8000 (irq = 59) is a IMX
console [ttymxc1] enabled, bootconsole disabled
imx-uart.2: ttymxc2 at MMIO 0x21ec000 (irq = 60) is a IMX

Output of /proc/tty/driver

/dev/tty             /dev/tty        5       0 system:/dev/tty
/dev/console         /dev/console    5       1 system:console
/dev/ptmx            /dev/ptmx       5       2 system
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster
rfcomm               /dev/rfcomm   216 0-255 serial
IMX-uart             /dev/ttymxc   207 16-23 serial
pty_slave            /dev/pts      136 0-1048575 pty:slave
pty_master           /dev/ptm      128 0-1048575 pty:master
pty_slave            /dev/ttyp       3 0-255 pty:slave
pty_master           /dev/pty        2 0-255 pty:master
unknown              /dev/tty        4 1-63 console

I tap this cat /proc/tty/driver/IMX-uart adn this is the output:

0: uart:IMX mmio:0x02020000 irq:58 tx:0 rx:0 DSR|CD
1: uart:IMX mmio:0x021E8000 irq:59 tx:12075 rx:358 RTS|DTR|DSR|CD
2: uart:IMX mmio:0x021EC000 irq:60 tx:0 rx:0 DSR|CD

Answer 1

Based on the positive results of the /proc/tty/driver/IMX-uart tests and the garbage data received, it seems safe to assume that Linux on your ARM board is sending output when you issue the shell command echo hello > /dev/ttymxc2. And we know that you have a good serial link between the host PC and /dev/ttymxc2, the serial console.

PART Ia

Normally the first item to check is the output of imx-uart.2 at its connector on the board. You would need an oscilloscope, and could confirm that the logic levels or RS-232 voltages seemed okay. This check is to also confirm that you're connected on the correct pin.

PART Ib

In the setup and the results (so far) that you have described, you have one working serial link and another serial link of unknown condition. The working serial link is:

---

<PC COM port_A> ----------(cable_A)-----------<imx-uart.1> 

and the other serial link consists of:

<PC COM port_B> ----------(cable_B)-----------<imx-uart.2> 

---

This testing assumes that all four serial ports are configured for 115200 8n1.

By selective substitution into the working link, you can verify that the components of the second link are functional.
For instance, the first substitution could be replacing the cable:

<PC COM port_A> ----------(cable_B)-----------<imx-uart.1> 

If the link to the console still works, then the next substitution could be swapping the the PC port connection:

---

<PC COM port_B> ----------(cable_B)-----------<imx-uart.1> 

And then the other serial link would now consist of

<PC COM port_A> ----------(cable_A)-----------<imx-uart.2> 

---

So now the second serial link is composed of previously-known working components and just one unknown, the port on the ARM board.
Redo your tests.

PART II

IF you still cannot get positive results from the swapping, then you need to provide more details of your setup. You mention something about USB. So apparently PC COM port_A and PC COM port_B are each a combination of USB port and somekind of RS-232-to-USB adapter?

Please provide details of the board connections for imx-uart.1 and imx-uart.1.
Are theses interfaces at RS-232 voltages or at logic level?
If logic level, then what are you using to convert to RS-232?

If you're using a FTDI USB-to-TTL-serial "cable", then that could be an issue. I had a problem with the FTDI "cable" connected to one SoC that had a slightly-slow baud rate and slow slew rates. The issue was that the received data was always total garbage characters. Replacing the FTDI "cable" with a USB-to-RS232 adapter and a MAX3232 converter (RS-232 to 3.3V logic) solved that connection problem.
Compared to the Sparkfun board and the FTDI "cable" (and its variants and knockoffs), I would recommend the use of a real TTL-to-RS232 converter (using a MAX3232 or similar chip) for reliability. Use the Sparkfun board or the FTDI "cable" only after you or someone has verified that the setup actually works.

In that situation I had, one serial port (on the SoC) was fixed at 115200 baud.
But you have full control of your situation.
So when you are receiving garbage data, one test to try is to reduce the baud rate (at both ends of the serial link) to 9600 or even 1200.