there is a bug for frdmk22f\rtos_examples\freertos_uart of KSDK2.1

cancel
Showing results for 
Search instead for 
Did you mean: 

there is a bug for frdmk22f\rtos_examples\freertos_uart of KSDK2.1

802 Views
phantomgz
Contributor III

Hi all,
I import the demo project "frdmk22f\rtos_examples\freertos_uart" that come from KSDK2.1

I use Tera Term to send some charactor to the target board, if I press keyboard continuing, the teminal would print "Hardware buffer overrun!", some time print "Ring buffer overrun!", and then the task suspend.

 

Cai.

Labels (1)
0 Kudos
2 Replies

368 Views
davidjurajda
NXP Employee
NXP Employee

Hi Cai,

 

thank you for your report. Described behavior is not a bug, but it is could be a gap in documentation. RTOS driver is blocking current task until whole required data are received. Data transfer is managed on background. So low level uart driver is feeding background buffer (ring buffer) and task is blocked by UART_RTOS_Receive() call. That enable execution of some another task without waiting and wasting of time.

 

Background buffer have limited size (in case of example 32B), So if the reading from ring buffer is slower than writing into it, buffer will overflow and corrupt data. To show this situation in example, data reading is slowed down by 1s delay (vTaskDelay(1000)).

 

Warning "Ring buffer overrun!" is triggered when there is no empty space in background buffer.

 

Try to paste 32+3 characters (Ring buffer size 32B, 4B are read immediately) into terminal (paste it by Alt+V in TereTerm or by right click).

 

    If you insert:

    "12345678abcdefgh12345678abcdefghxxx"

    terminal will print out four bits in each second without warning:

    1234<1s>5678<1s>abcd<1s>efgh<1s>1234<1s>5678<1s>abcd<1s>efgh

 

First four bytes were immediately received ("1234") and rest of data became stored into ring buffer (application will read data after 1s, but transmission is very quick). Checkout background_buffer in watch window after UART_RTOS_Receive(). Ring buffer is almost full "5678abcdefgh12345678abcdefghxxx", but there is still one empty byte => no warning appears.

 

but if you insert 32+4 characters at once warning appears.

    If you insert:

    "12345678abcdefgh12345678abcdefghxxxx"

    terminal will print out four firs bits and warning:

    1234

    Ring buffer overrun!

 

First four bytes were immediately received ("1234"),but ring buffer was fully loaded with data with no empty space. This situation trigger kStatus_UART_RxRingBufferOverrun returned from UART_RTOS_Receive().

 

RTOS driver uart_freertos is able to receive only 31B of data between two calls of UART_RTOS_Receive() in case of 32 B ring buffer (background_buffer in example).

There is also second buffer which can overflow. It is part of lpuart hardware and in example is called "Hardware buffer". You can try to put break point into UART_RTOS_Callback in fsl_uart_freertos.c. It will block data flow to ring buffer and it will cause overflow of hardware buffer.

 

The example showing that even if the application is not able to handle incoming data quickly enough, the status of UART_RTOS_Receive is always able to give information if the data are consistent or not because of overflow.

 

So take away note is, uart data can be broken by buffer overflow if application is not reading fast enough, but application can be aware of it because of returned status.

Regards,

David

0 Kudos

368 Views
phantomgz
Contributor III

Hi David,

  After reading your post, I understand what is the example want to telling me. I think it's a bad idea to telling user running me like that would have wrong result. it should tell the user is,  running me you can running well, and this is the proper way to using all the API that introducing in here.

  I'm not the only one being stuck in this example. you can read this post(write in chinese)

   http://www.nxpic.org/module/forum/thread-608196-1-1.html

anyway, thanks your answer.

Regards,

Cai

0 Kudos