Problems with RS-232 Serial Comunication

Technical Support
, ,
1

Good afternoon, my name is Gabriel, I work at MWF-Dynamics.

I am involved in a project where we are using the Apalis iMX8 module and an Apalis Evaluation Board. The Linux version we are using is the one generated in yocto, based on this article:

The scenario is as follows: We have a device that sends a 54-byte message periodically over the serial and we want to receive, process and extract the measurements from that message.

To handle this data, a simple c++ program was created that configures and watches the iMX8 serial waiting for the data that is sent by the device. As soon as the device sends the 54-byte message, the program processes and returns the measurements.

This device in question supports various baudrates and the frequency of sending messages is also configured on it.

For transmission frequencies less than 100hz → baudrate: 115200
For transmission frequencies between 100hz and 200hz → baudrate: 230400
For transmission frequencies between 200hz and 400hz → baudrate: 460800

Our problem here is not being able to receive the message correctly on the iMX8 when the sending frequency of the device exceeds 50hz. For frequencies higher than 50hz it seems that the iMX8 allocates the messages and delivers me in a much longer period than the message actually arrived for it causing me to always receive the late measurements.

An interesting piece of information is that the device in question also has an integrated USB-Serial converter, and using the virtual serial port generated by the device when connected via USB, my program normally receives the 54 bytes for all configurable send frequencies on the device ( 1 - 400hz).
That is, the same c++ program that keeps looking at the iMX8’s physical serial, when configured to look at the virtual serial, works correctly. After this test I “discarded” the possibility of being a processor or code bottleneck.

I put the device on the oscilloscope to confirm that it is sending the message with the correct length and period and it really is!

Another test done by me was to configure a second serial port to send a message of 54 bytes periodically to another serial port and again for frequencies higher than 50 hz the reception of the message is lost.

I would like to know if anyone has any information about any limitation in the frequency of reception of the physical serial of the iMX8 or if you have experienced a similar problem.

Thank you in advance for your attention and apologize for the length of the text. I decided to list here the complete scenario and the main tests I ran to better describe the problem.

2

You mentioned that when using the USB-Serial converter, data seems to be received correctly. Did you also scope that line and verify that the transaction speeds are the same as when you aren’t using the converter? Just seeing if this is an apples-to-apples comparison.

Also, are we talking about rs232, rs485 or some other communications protocol?

1 Like
3

Thanks for the answer!

When we use the device in USB-Serial mode it remaps the UART pin that was going to the UART-RS232 transceiver to the USB-Serial converter. The analysis I did was looking directly at the device’s UART. So we can confirm that the signal is the same.

The protocol I am using on the physical serial port of both the device and the iMX8 is RS-232.
As for the protocol that goes through the USB virtual serial port, I don’t know… I believe it is a virtualized implementation of a physical serial port over the USB protocol.

4

Does data get lost or is it just not available fast enough for you? As in, if you let it run for a while then turn off the external device, does all of the serial data eventually make it into your app?

Perhaps the USB piece is buffering the incoming data a bit differently. I know in the past I’ve had to muck around with termios settings to the serial drivers of various uarts to get things to respond how I wanted.

1 Like
5

Apparently some data was lost, yes. But the strangest thing is the observed behavior.
The data is available for analysis after buffering 2,048 bytes, which gives me approximately 37 samples.

This considerably delays my reception, making the first sample available for use only 36 samples later!

The configuration I did in terms was very simple, based on receiving raw data and using the O_NONBLOCK flag. But I did tests using several other settings and even so the strange behavior is repeated.

Dear DaveM, I greatly appreciate your willingness to share your experiences and help think of a solution!

6

That 2048 byte thing looks interesting. Perhaps turn off DMA for that uart? There are some notes in UART (Linux) | Toradex Developer Center about Enabling/disabling DMA

1 Like
7

I analyzed the article you indicated and went after turning off the use of DMA by the RX. However, when going to the device tree of the Apalis Evaluation Board I noticed that the use of DMA is not enabled for any of the serial ports.
I really thought this tip could solve my problem, thank you for thinking about it…

For now I can’t think of anything else that might be disrupting reception.

If I get any advances here, I’ll come back to update the post.

8

Hello @gabriel, it seems that you’re facing problems related to the buffering of the serial port. By default serial ports are buffered (at the OS level) and setup to be line oriented. In this case, the input is buffered until either a newline is found or the maximum buffer size is reached.
I don’t know if your serial messages are ASCII based or binary, but if you need to limit the size of the buffer you can try to disable the canonical mode (especially if you are sending binary messages) and then tweak VTIME and VMIN parameters in your termios structure.

Here’s a link that describes the process:
https://blog.mbedded.ninja/programming/operating-systems/linux/linux-serial-ports-using-c-cpp/
Also, the manpage for termios has a lot of information if you need other details on how the flags work.

Please let us know if this helps!
Best regards,
Rafael

9

Good morning, Rafael!
Well, the message of the device in question is binary and in the termios configuration I have already configured it as “no canonical”.
Thank you very much for your availability to respond and apologize for the delay in returning.

All these possibilities that you indicated I have already checked, what was defined here internally was to use what is working. At first we adapted our application to this serial port limitation.

big hug and thanks again