UART FIFO appears empty even though it is not (K64 & MQX 4.1)

tmeyer · ‎02-12-2015

Hi,

I have a somewhat rare issue with my UART RX FIFO. The K64 UART is connected to a half duplex RS485. I haven't pinned down exactly how to cause the issue yet, but it seems to occur more frequently when I send lots of contiguous serial data. If I had to guess, it would be caused by a bit r framing error on the UART bus.

Setup:

- K64 & MQX 4.1

- UART1 interrupt mode (8N1 @ 115200)

- RTS pin controls RS485 flow control (flag: IO_SERIAL_HW_485_FLOW_CONTROL)

The symptom:

Once the issue occurs, it never seems to go away until I reset the K64. As an example: the master will send a packet of say 10 bytes to the k64 slaves on the rs485 bus. Then the k64 will read one byte at a time from the UART driver. The following function is used to determine if data is ready to be read:

_io_ioctl(port, IO_IOCTL_CHAR_AVAIL, &ready);

When the issue occurs, I can read say 6 bytes from the UART buffer, and then ready becomes FALSE, even though there is still 4 more bytes that should be ready. This function will continue so indicate no data is ready until an additional byte is sent by the master, in which case I will be able to ready 1 more byte from the UART driver.

It seems as if the data is stuck in the FIFO, but is not accessible. I have put a sniffer on the bus to confirm that the data wasn't being cached in the master side UART and can see all the data on the bus. I've also had multiple k64's on the same bus all receiving the same data and some of the K64s will receive all the data properly and others will get into this erroneous state.

Seems to be related to: K22 MXQ4.02 serial port will miss characters if paste a lot of commands together(cause overflow and ...

Any help would be appreciated.

Thanks,

Tim

johannesschock · ‎02-18-2015

Hello, I had a similar Problem with other Kinetis (K70/60/10) and after some heavy debugging I think there's a hardware bug in the Kinetis Uart module.The Kinetis Uart itself has a internal FIFO (some chips more deep, some chips less deep). After a overrun of this FIFO occurs (a character isn't fetched by IRQ when it is already full and a new one arrives) this FIFO stops functioning: Write and read pointers of that Hardware FIFO will have an offset afterwards, which means you will get your following characters with a delay. The Interrupt for character n+1 lets you read character n, the Interrupt for character n+2 lets you read character n+1 and so on.

After messing around with that problem I found the following solution (more or less empirically):

Locate all occurences of

   if(stat & UART_S1_OR_MASK) {
      ++sci_info_ptr->RX_OVERRUNS;
   }

and replace it with

  if (stat & UART_S1_OR_MASK) {
    sci_ptr->CFIFO |= UART_CFIFO_RXFLUSH_MASK;
    sci_ptr->PFIFO &= ~UART_PFIFO_RXFE_MASK;
    c = sci_ptr->D;
    sci_ptr->PFIFO |= UART_PFIFO_RXFE_MASK;
    ++sci_info_ptr->RX_OVERRUNS;
  }

The locations are in

serl_pol_kuart.c and in serl_int_kuart.c

Hope it helps.

View solution in original post

samyukthas · ‎04-24-2017

Hi Alex,

I have been receiving the Null at the end of transmission on K22 while using it as RS485.

It would be really helpful if you could suggest how to eliminate the same.

Samyuktha

dave408 · ‎12-14-2015

Yes, I should probably have put the callback check into the if statement right before it... thanks for catching that. :smileyhappy:

dave408 · ‎11-09-2015

Thanks, Carlos, I hadn't scrolled down all the way and read your response from August. I appreciate your replying to my needless post. :smileyhappy: I'll work on investigating a fix today!

tmeyer · ‎07-17-2015

Does anyone know if this was ever documented as an Errata for the kinetis parts? I have encountered this same issue again.

I would like to determine if the newer rev's of certain processors have fixed this.

Tim

yb · ‎05-05-2015

Fixed for me too, thanks a lot !!!

It was a long long problem for me...

Yvan

tmeyer · ‎02-18-2015

That fixed it.

Thanks.

tmeyer · ‎02-17-2015

Hi,

Thanks for the response. This doesn't appear to be related to the IOCTL_CHAR_AVAIL. I can reproduce the same issue using a simple polled UART0 connected to the shell. After sending arbitrary data to the shell, it will then start echoing characters that were sent 1-3 keystrokes ago. (I double checked this with a scope to ensure I was sending the correct chars).

Upon debugging it in this state, it is clear that there is nothing to be read since there are 0 chars in the uart driver CHARQ. Also, the UART peripheral registers indicate that the RX FIFO is empty:

Serial Communication Interface (UART0)
	UART0_BDH	0x00	0x4006a000
	UART0_BDL	0x36	0x4006a001
	UART0_C1	0x00	0x4006a002
	UART0_C2	0x0c	0x4006a003
	UART0_S1	0xc0	0x4006a004
	UART0_S2	0x40	0x4006a005
	UART0_C3	0x00	0x4006a006
	UART0_D	0x62	0x4006a007
	UART0_MA1	0x00	0x4006a008
	UART0_MA2	0x00	0x4006a009
	UART0_C4	0x08	0x4006a00a
	UART0_C5	0x00	0x4006a00b
	UART0_ED	0x00	0x4006a00c
	UART0_MODEM	0x00	0x4006a00d
	UART0_IR	0x00	0x4006a00e
	UART0_PFIFO	0xaa	0x4006a010
	UART0_CFIFO	0x00	0x4006a011
	UART0_SFIFO	0xc5	0x4006a012
	UART0_TWFIFO	0x07	0x4006a013
	UART0_TCFIFO	0x00	0x4006a014
	UART0_RWFIFO	0x01	0x4006a015
	UART0_RCFIFO	0x00	0x4006a016
	UART0_C7816	0x00	0x4006a018
	UART0_IE7816	0x00	0x4006a019
	UART0_IS7816	0x00	0x4006a01a
	UART0_WP7816T0	0x0a	0x4006a01b
	UART0_WP7816T1	0x0a	0x4006a01b
	UART0_WN7816	0x00	0x4006a01c
	UART0_WF7816	0x01	0x4006a01d
	UART0_ET7816	0x00	0x4006a01e
	UART0_TL7816	0x00	0x4006a01f

What I also find interesting is that if I physically unplug the TTL level UART cable from the processor and plug it back in - the characters will start coming in correctly. It is as if, the

Thanks,

Tim

matthewkendall · ‎02-17-2015

there are 0 chars in the uart driver CHARQ

The CHARQ struct (as defined by psp/PSP_Generic/include/charq.h) includes not only head and tail indexes (.HEAD and .TAIL) but also a count of the number of chars in the queue (.CURRENT_SIZE). This is clearly redundant and is likely included as an optimisation.

In other contexts I have had trouble with CHARQ where the count became inconsistent with the head and tail indexes. This should not be possible if the CHARQ is always accessed via the provided macros. But there is no flush macro for example, so it is possible that someone decided to directly access the struct. It might be worth investigating if something in the serial driver can cause a problem, for example by directly setting CURRENT_SIZE to zero to flush the queue without making corresponding change to HEAD and TAIL. In your error state it might be worth checking to see if the CHARQ is self-consistent.

tmeyer · ‎02-17-2015

Thanks Matthew for the replay.

I looked into the CHARQ and it appears that it is behaving as expected. I can step through the code and see the old character(and not the one most recently typed).

ex:

Sequence of events:

Type "12" into the shell
The final character enqueue via _CHARQ_ENQUEUE in the_io_serial_polled_read() function is the '1' character. (Not the '2' as expected).
_kuart_polled_status() indicate that the RX FIFO is empty: UART_SFIFO_RXEMPT_MASK is set, and RXCOUNT in the RCFIFO register is also 0.
"1" is echoed to the shell console
Type "3" into shell
The '2' character is now enqueued via _CHARQ_ENQUEUE in the_io_serial_polled_read() function.
_kuart_polled_status() indicate that the RX FIFO is empty: UART_SFIFO_RXEMPT_MASK is set
"2" is echoed to the shell console

This appears to me that the serial peripheral is somehow caching these characters in it's FIFO or elsewhere. It seems incorrect to me that the FIFO indicates it is empty, however a byte that was sent to the UART prior shows up after sending a new byte. Is there a chance there is an errata relating to the hardware peripheral?

Thanks,

Tim

soledad · ‎02-13-2015

Hello Tim,

Could you please confirm if the Matthew's suggestion helps???

Have a great day,
Sol

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

matthewkendall · ‎02-13-2015

This issue maybe?

Re: Bug Report: In MQX 4.1 change of size of bool can cause stack corruption