Flushing UART FIFO buffers

Technical Support
, , , ,
1

In our case the serial port receives data before it is initialized correctly (baudrate, etc.). This is usually solved with a tcflush() after tcsetattr(). But with the current BSP2.8 kernel there still seems to be bogus data in the FIFO. Shouldn’t lpuart_flush_buffer() in the fsl_lpuart device driver flush the UART FIFO buffers?

Something like:

writeb(UARTCFIFO_TXFLUSH | UARTCFIFO_RXFLUSH, sport->port.membase + UARTCFIFO);
2

hi @tcone and Welcome to the Toradex Community!

Could you provide the version of the hardware of your module?

But with the current BSP2.8 kernel there still seems to be bogus data in the FIFO.

Could you provide an example code, how did you check this?

Shouldn’t lpuart_flush_buffer() in the fsl_lpuart device driver flush the UART FIFO buffers?

Usually this function should empty the lpuart. Could you try to make a pause ( sleep(1) ) after you call the flush_buffer and check if this solves the issue?

Best regards,
Jaski

3

Hi @jaski.tx

Hardware revision is 1.2B.

You’ll find example code attached.

There are 8 bytes transmitted every 2 seconds, e.g.

07 01 ff 11 08 06 fe ae

But what is received seems odd, because we first get some zeros before the first byte is read correctly. And after the first byte read() blocks and the remaining 7 bytes can be read 2 seconds later.

00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 07
01 ff 11 08 06 fe ae 07

I admit this being a bit of an edge case because we can only reproduce it the first time opening the serial line after rebooting. And it’s important that data is transmitted before executing the example code provided.

4

Hi @tcone

Thanks for the code. I tested your code, but I could not reproduce the issue. I noticed that you are using ttyLP0 in your code. This oort is usually used as Console Output. Did you disable the console in the Software? Could you try to use a different Port and check if the issue occurs also there?

Best regards,
Jaski

5

Hi @jaski.tx

I can confirm that it seems to be working fine on ttyLP2. We boot with console=null and we don’t start getty on ttyLP0, that can’t be the cause.

The issue does only occur in case data is transmitted to ttyLP0 before starting the provided example. Everything works as expected if data transmission begins after starting the example.

But the thing is, when I add the following line to lpuart_flush_buffer() the issue is gone:

writeb(UARTCFIFO_TXFLUSH | UARTCFIFO_RXFLUSH, sport->port.membase + UARTCFIFO);
6

Hi @tcone

Thanks for your Input.

I can confirm that it seems to be working fine on ttyLP2. We boot with console=null and we don’t start getty on ttyLP0, that can’t be the cause.

Do you really need ttyLP0 for your application? You should use different Uart Interface, since ttyLP0 is usually reserved as DebugPort.

But the thing is, when I add the following line to lpuart_flush_buffer() the issue is gone:

That’s good that you have found a workaround.

Best regards,
Jaski

7

Hi @jaski.tx

Do you really need ttyLP0 for your application? You should use different Uart Interface, since ttyLP0 is usually reserved as DebugPort.

Our custom board has to be compatible with older PXA270 modules and we need flow control, therefore we unfortunately have to use these two ports.

8

Thanks for your Input.