Bad UART performance on MK64

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bad UART performance on MK64

1,476 Views
simonhaines
Contributor III

I am porting an application from the K20DN512ZM10 to the MK64FN1M0VLQ12 and am having problems with running the UARTs at high baud rates.

The K20 application has a clock speed of 96MHz and receives data from the UART and places it on a FreeRTOS queue and has no problem communicating with a RS485 transceiver at 460800 baud.

The MK64 application has a clock speed of 120MHz and manages the UART through the KSDK 2.4.2 (fsl_uart_freertos) and frequently receives kStatus_UART_RxHardwareOverrun when trying to read bytes. I have increased the priority of the interrupt (UART1_RX_TX in this case) but this does not help.

When configuring the UART through the SDK, the desired baud rate (461538) is within 3% of the actual rate (the difference is 738 and the tolerance is 13824, so I don't think there is a clock issue. 

I also had this problem with another UART receiving data from a uBlox GPS module and in that case I had to reduce the baud rate to 115200 to get the number of hardware overruns down to an acceptable level. Note these are definitely hardware overruns, not ring buffer overruns.

I was expecting better performance from the MK64 over the K20, but instead it is worse. Why are there so many hardware overruns?

Tags (4)
0 Kudos
6 Replies

1,070 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Simon,

     As I know, the normal UART error rate should lower than +/-1.5%, 3% is too larger, do you mean your GPS module can accept 3% error rate? It's really too high.

   Actually, this problem is note the K64 project, it is just the UART error rate is too high, I think you can change the K64 bus clock which is the UART clock source, you must make sure the selected bus clock can get the uart baud rate error rate is lower than 1.5%.  This problem is no relationship with the K20.


Have a great day,
Kerry

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

0 Kudos

1,070 Views
simonhaines
Contributor III

Thanks Kerry, the KSDK for the MK64F (fsl_uart.c) enforces the actual baud rate is within 3% of the requested baud rate in UART_SetBaudRate(). With my clock configuration, the actual baud rate is 0.16% of the requested baud rate, so it is well within tolerance.

If there was a clock issue, I would expect noise or framing errors. Instead Rx hardware overrun errors indicate that received data is not being read fast enough.

I have abandoned the FreeRTOS mode in the MCUXpresso peripheral config tool and written my own interrupt handler that is able to process 460800 baud data without any Rx overrun errors at all. I believe the interrupt handler in the fsl_uart_freertos module is too long or has a bug that misses incoming data and causes overrun.

Have a great day.

Simon.

0 Kudos

1,070 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Simon,

   Sorry for my later reply!

   Today, I have tested the SDK_2.4.2_FRDM-K64F\boards\frdmk64f\rtos_examples\freertos_uart\iar

Change the baudrate to 460800 bps, then test it as follows:

pastedImage_1.png

You can find, FRDM-K64 can receive the input data and output it back.


Have a great day,
Kerry

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

0 Kudos

1,070 Views
simonhaines
Contributor III

Thanks Kerry, I think I was being over-ambitious with how much the Kinetis UARTs can handle. Multiple peripherals on 460800 baud will cause Rx overrun, even at 120MHz.

Simon,

0 Kudos

1,070 Views
mjbcswitzerland
Specialist V

Hi Simon

460kBaud requires an rx interrupt to be handled every 23.8us and whether there is a risk of over-runs (with FIFO the receiver can bridge several such intervals before loss) depends on the time the UART Rx processing takes and also whether higher priority interrupts block/delay the UART interrupt.

In situations where the UART interrupt processing can become critical or represents a high CPU loading in the overall system you should use DMA since that will allow guaranteed operation with negligeable CPU overhead. Even at low CPU speeds fast UARTs are then not an issue.

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K64:
- http://www.utasker.com/kinetis/FRDM-K64F.html
- http://www.utasker.com/kinetis/TWR-K64F120M.html
- http://www.utasker.com/kinetis/TEENSY_3.5.html
- http://www.utasker.com/kinetis/Hexiwear-K64F.html

For less questions and restrictions, and faster, cheaper developments: try uTasker for Kinetis

0 Kudos

1,070 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Simon,

   Do you just test our SDK with one UART module directly? At least it works on my side with 46800.

   Besides, if you don't use the freertos, whether it works OK or not with multiple peripherals, you can test the SDK driver project.

  


Have a great day,
Kerry

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

0 Kudos