Getting Started Guide Basic UART usage

I am trying to follow the Linus getting started guide for the Colibri VF61 and Colibri evaluation board. I am having trouble in the section Basic UART usage. Following the instructions, I have jumpered UART-B Tx to Rx (connector X12 pin 17 to pin 16). I then execute the following commands:

stty -F /dev/ttyLP1 9600 -echo
cat < /dev/ttyLP1 &
echo "Testing UART" > /dev/ttyLP1

But I see no echo of the “Testing UART” string.

I noticed that the UART-B Tx and Rx signals were connected to both an RS232 tranceiver and an RS485 tranceiver on the evaluation board. I know they should both be disabled for the loop back to work, and I was not sure which jumpers would disable the transceivers. So I decided to remove the jumpers between X10 and X12 pins 16 and 17, and jumper X10 pin 17 to pin 16 for the loop back. It still does not work.

I should also note that when I execute the command:

cat < /dev/ttyLP1 &

I see something like this on the terminal:

[1] 274

And each time I execute that command the numbers seem to increment. Finally I decided to remove the loop back jumper and attach an oscilloscope to the UART-B Tx pin. I used echo “string” > /dev/ttyLP1 (with a long text string and ttyLP1 set to a low baud rate), but I verified that no data was sent out the Tx data pin. The pin simply stayed at 3.3V.

Why doesn’t this simple UART demo work? Am I doing something wrong? I seem to be stuck at this point in my evaluation.

Are you sure you are talking to the UART you think you are talking to (e.g. see here)?

How am I supposed to know if I am talking to the right UART? I am following the instructions in the Getting Started Guide, which I quote as follows:

Step 4

A loopback test will be run from command-line. This will send and receive data from the same serial port to verify if it’s working.

Connect your board’s UART_B TX pin (X12.17) to its RX pin (X12.16).

Colibri UART Wiring

Colibri UART Wiring

Step 5

From a serial terminal connected to the module, configure the UART_B baud rate using the stty command. We will use a baud rate of 9600 baud:

stty -F /dev/ttyLP1 9600 -echo

Use the cat command to listen for incoming data on the serial port:

cat < /dev/ttyLP1 &

Write to the serial port. The characters sent will be printed back to you in the next line:

echo “Testing UART” > /dev/ttyLP1

Testing UART

So the Getting Started Guide clearly states that I should be using ttyLP1, while the page you reference clearly states that I should be using ttyLP2. So which is right? How would I know? I guess I’ll just play around and try this and that and see if anything works. I am just using the Getting Started Guide as a way to evaluate the VF61 SOM, and so far it has not been an easy task. This is no way to introduce a potential new customer to the Toradex modules.

Sorry, this was really wrongly advertised in the getting started guide. We fixed this now. Please try again with the UART device as previously suggested. Thank you very much for reporting this!

There are so many errors in the Getting Started Guide Basic UART Usage that I hardly know where to begin.

First of all UART_B was incorrectly identified as /dev/ttyLP1, when it should be /dev/ttyLP2. This has been corrected, but there are more errors.

Step 4 instructs me to loop back UART_B Tx to UART_B Rx by jumpering X12.17 to X12.16. This will not work because UART_B RXD is driven by both IC10A and IC9. Both of these would need to be disabled. Since I don’t know what jumpers are necessary to disable these tranceivers, I simply removed the jumpers X11.17 and X11.16, and instead jumpered X10.17 to X10.16.

Then there are a bunch of extra “” characters in the Loopback example code in steps 9 and 10. It won’t compile with those extra characters there!

Finally, the Loopback test code in step 11 is different from the code in steps 6-10 (just to confuse the user). In particular, the code in step 11 uses the same buffer (buf) for both sending and receiving data. This causes a MAJOR software bug. A text string is copied into buf, and buf is sent out the serial port. Then the serial port is immediately read with the read function. But it takes some time for the data to actually be sent out the serial port, and it cannot be received before it is sent. Since the serial port was opened in non-blocking mode the read will return immediately with an error, indicating no data is available. But the program doesn’t bother to check for an error, and simply prints the contents of buf. It appears as if the echo back was received properly, but in fact no data was received at all. The program is simply printing the data in buf that was put there to be sent. It looks like everything is working fine, but in fact the program is completely broken and no data was received.

Between the documentation problems, the hardware problems and the software problems I wasted a lot of time on this getting started example.

We are really sorry about that. We updated the getting started guide some more hoping to have addressed all shortcomings mentioned. Thanks again for your patience.