We might be doing something wrong here, but whatever we try we don't get parity errors detected.

In our setup we are using base64 encoding to transfer binary data as text, so frames are started with STX (0x02) and terminated by ETX (0x03). We precede the STX by 2 PREAMBLES on transmit and require minimum 1 on receive. This way we can always correctly detect the start and end of a frame.

In the ideal case a char with a FE or PE should be translated to 0x00, but whatever we try this doesn't happen.

To test this we used 2 Edisons happily talking to each other at 8bit, 2Mb/s, 1 stop bit, however one is using parity EVEN, the other ODD. This means that a PE happens on every char received. This has been verified by our oscilloscope which has a very clever 'serial decode' function and shows PE for each decoded byte. But the Edisons are both ignoring the PE and not replacing the error byte by 0x00 (or prefixing by 0xFF 0x00, or discarding the char completely). We know the messages are received entirely without errors because we use a CRC32C on the message (after base64 decoding) and toggle a GPIO on success).

Apparently the HSU is not using n_tty.c line dicipline, but doing a new implementation.

In lines 1341 is the serial_hsu_set_termios function, that should be taking care of IGNPAR, INPCK, PARMRK flags (line 1499 - 1517).

We are using MRAA but using the following code to configure the port, because not everything can be set in MRAA (and because of bugs in MRAA we had earlier). I honestly can not see what we are doing wrong here, and I am starting to suspect a problem in the hsu kernel code (although I can't find that problem in the mfd_core.c ref'd above).

The whole problem should be easily reproducible using 2 Edisons (with Arduino carrier) and connecting RX-TX and vice versa (as well as the GND). Our code is here https://github.com/htot/hs_uart. If you allow me a day or so, I will push our latest code, which in addition has a command line option to switch from parity ODD to EVEN so you only need to use a single executable on both edisons ./hs_uart for ODD and ./hs_uart -e for EVEN. I will post back here when that has happened.

New code uploaded here https://github.com/htot/hs_uart. This should allow to reproduce the issue. A quick test to see if the code works would be to loop back the TX and RX and start with the -d option and let it run for a bout 10 seconds. Certain timings are collected and displayed at the end of the run. The program stops when a key is pressed.

We will try to reproduce it and we will let you know our results.I’m wondering if you have tried our suggestions from this other thread: https://communities.intel.com/thread/104815. Did you try to edit the configuration from the menuconfig (and then copying the generated defconfig file)? We would like to know if you had any different results.

But thinking about the dma question a bit deeper: it's probably not the dma that is causing the delay, but the fifo. And when the fifo is used looking from the code, when a parity error occurs the whole fifo is marked with a parity error (this is not what we are seeing though). So what we probably would need is to set the fifo trigger to 1 byte to effectively disable the fifo and keep dma to make sure the uart get's serviced on time.