UART frame/parity error with MQX 4.1

cancel
Showing results for 
Search instead for 
Did you mean: 

UART frame/parity error with MQX 4.1

1,052 Views
liudachuan
Contributor I

We are working on K60N512 and MQX 4.1. There are 9 serial ports on the board and 5 of them are K60's build-in SCI port and the other ports are expended by a uart tranceiver(TL16C754).

Our board is the RS-485 master device, it sends modbus querry frames and the slave device will response immediately. We find that when our board is receiving data from slave device, three build-in SCI ports loss characters occasionally. We trace the code and find every time the UART loss character, the S1[PE] and S1[FE] flags are set.
It seems there are some frame errors or parity errors on the Rxd line. But we capture the signals by logic analyzer when the PE/FE interrupt triggers, every thing is fine, we can't see any abnormal signal.
The problem is only on UART2/3/4, not on UART0/1 which have 8-entry FIFOs and expend UART tranceiver.


We did some tests below, it seems the problem is somehow related with the MQX's interrupt/schedule machanism.
Test 1:
The default systick is 200, when we turn it to 100, it works fine. Then we turn it to 400, the problem occurs more frequently. And then we turn it to 600, it gets back to normal again.

Test 2:
We setup a test project and leave only two UART thread and one IIC read/write thread, the problem is still. When we remove the IIC thread, it's fine.

If we replace the IIC thread with a hwtimer task that rises up to 3000 interrupts per second, we can reproduce the UART module's problem.

We believe that the parity and frame errors should be pure hardware/CPU faults, and we can't explain why it's related with the software and OS.

Any one can help?
Thanks!

Tags (3)
0 Kudos
6 Replies

330 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi

I suggest you enable DMA to see whether it helps or not.

0 Kudos

330 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi

which mode your uart is working, polling mode or interrupt mode?

Regards

Daniel

0 Kudos

330 Views
liudachuan
Contributor I

Thanks for your reply.

We are using interrupt mode in our code. The SCI's interrupt priority is 3.

And we have successfully reproduced the problem in our custom board of K60DN512 AND TWR-K60F120M board.

To reproduce the issue, we can tart a task reading the ittyX:'s data and then send it back. And then start two hwtimer with freq 2500 and 4300hz and set these isr's priority to 5, in the hwtimer callback we call _int_disable() and set a short loop to waste cpu's time.

So we manually create a situation that a lower priority interrupt preempts a higher interrupt. Normally at this time, when chars come to the UART's rx pin, a OverRun interrupt should be rised because of interrupt delay. But we only get Parity Error and Frame Error flags, we believe that's a problem.

Are you Chinese? If yes, you may call me back.

Thanks!

0 Kudos

330 Views
danielchen
NXP TechSupport
NXP TechSupport

Can you set different uart with different priority, and try again, another question is,  did you enable flow control?

0 Kudos

330 Views
liudachuan
Contributor I

We tried different uart and change the interrupt priority to 5, the problem is still.

We are using RS-485 bus so the IO_SERIAL_HW_485_FLOW_CONTROL flag is added. But we measured the signal of the bus, there's no conflict and other abnormal timing.

0 Kudos

330 Views
RadekS
NXP Employee
NXP Employee

Errata e7091:

Description: While the UART_S1[FE] framing error flag is set the UART will discard any received data. Even though the data is discarded, if characters are received that include noise or parity errors, then the UART_S1[NF] or UART_S1[PE] bits can still set. This can lead to triggering of unwanted interrupts if the parity or noise error interrupts are enabled and framing error interrupts are disabled.

Workaround: If a framing error is detected (UART_S1[FE] = 1), then the noise and parity error flags can be ignored until the FE flag is cleared. Note: the process to clear the FE bit will also clear the NF and PE bits.

So, I suppose that this could partially explain missing character and parity error.

Now we should thinking about reason why you detected framing error.

Since you didn’t detect framing error in case of UART0 and 1, I suppose that baud rate will not be root cause. Anyway, could you please measure bit time by oscilloscope at RX and TX signals? It should fit. Calculating of allowed difference depends on more parameters, but we can say that in maximum difference should be below 2%.

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos