i.mx28 auart data loss

[mehmet]

Hello all,

I have serious problems on i.mx28. We used i.mx28 with L2.6.35_MX28_SDK_10.12_SOURCE for 3 years but never finished problems. Last we got auart data loss problem. If we use cdc-acm modem(telit he910), somehow cpu is blocked and auart data losses occurs(overrun errors). If I enable DMA for auarts, it is better but after a few time, dma stall problem occurs for sound device and sound gets interrupted. I.mx28 has big problem about dma and we couldn't find any solution for years.

Thanks.

Mehmet

[jonathanben-avr · Accepted solution]

Hi Mehmet,

The source of the problem is that the PL011 AUART FIFO's on the i.MX28 are only 16 bytes deep, and there is no way to ensure that at data rates above 9600 BAUD the Linux kernel will service the AUART receive interrupt before an RXFIFO overflow occurs.

Unless your application can use RTS/CTS flow control you cannot solve this problem with any existing mainline Linux kernel or Freescale device driver.

In this situation a kernel or BSP upgrade will not help you. In this situation using an RT_PREEMPT kernel will also not help you because the RX interrupt and FIFO overflow can occur while the kernel has masked interrupts.

In order to solve this problem I wrote a FIQ UART driver. The driver uses the ARM FIQ mode to handle the UART interrupts. I published a draft of the code on github at benavrhm/mxs-auart-fiq · GitHub. There is still some cleanup work to do on the published code. Review the code. If it looks interesting to you I will make an effort to clean it up.

Best regards

[cono]

Hi Jonathan,

why should using receive DMA not solve the data-loss problem? The DMA rx buffer is one page size (4 kB). Shouldn't this be enough to avoid data-loss?

Regards,

Christoph

[jonathanben-avr]

Hi Christoph,

There are two separate problems to deal with when working in Linux with the i.MX28 application UARTS. These are really Linux problems, not i.MX28 UART problems.

1. Serial driver operation latency
2. Line protocol latency

The serial driver latency is time required from receiving the DMA interrupt to the time that the Linux serial driver removes the data from the DMA buffer. Since in Linux there is no way to guarantee the maximum latency of any interrupt handler, it can always be that a previous interrupt or exception handler will not relinquish the CPU until the UART DMA buffer is full and the RX FIFO overflows. Practically speaking, the maximum latency at 115200 baud for the serial interrupt handler must be less than 500 milliseconds. In many applications this is usually plenty of time, but in some applications even a 4K DMA buffer will not be enough to ensure reliability of reception in exceptional circumstances. The data loss problem occurs then in circumstances where hardware flow control is not possible (such as telemetry) and unpredictable combinations of interrupts or exceptions cause the latency to be more than the maximum, and the application is critically sensitive to data loss.

The line protocol latency is the maximum time required to react to incoming data. For example, if you receive synchronous 32 byte frames of data at a relatively slow speed of 57600 baud and you must send response frames only during the time gaps between frames, the Linux interrupt handling model has no way to guarantee that the serial driver will be able to send the responses in time, even when no received bytes are lost.

In the serial applications that I wrote, DMA was not a solution because the message size was small, no data loss at all could be tolerated, and responses had to be sent in the inter message gaps. The FIQ driver was the only solution.

[mehmet]

Hi Jonathan,

Thank you for your response, I will try your fiq mode code and write result.

Best regards

Mehmet Kurnaz

[jonathanben-avr]

Hi Mehmet,

The published code might not work for you out-of-the-box.

Don't hesitate to send me questions about the driver and how it works. I'll try to put answers to the questions in comments in the code and fix any bugs you find. Probably best to send questions to me off-list. I sent you a LinkedIn invite.

[jimmychan]

there is a newer BSP for i.MX28.

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX28EVKJ&fpsp=1&tab=Design_Tools_T...

hope this can help you.