i.MX RT Crossover MCUsのトピックRe: RT1050 - LPUART RXWATER documentation error

RT1050 - LPUART RXWATER documentation error

dmarks_ls — Mon, 13 May 2019 18:59:04 GMT

Just fixed a bug in my custom LPUART driver, which was introduced only because there is a false statement in the RT1050 reference manual (rev. 2, 11/2018). On page 2714, it states (emphasis added):

RXWATER -- Receive Watermark
When the number of datawords in the receive FIFO/buffer is greater than the value in this register field,
an interrupt or a DMA request is generated. For proper operation, the value in RXWATER must be set to
be less than the receive FIFO/buffer size as indicated by FIFO[RXFIFOSIZE] and FIFO[RXFE] and must
be greater than 0.

The last part of that statement is simply false. If RXWATER is greater than zero (say, N), then my LPUART ISR will not trigger until N+1 characters have been received. Per the manual, I had set RXWATER to 1; this manifested as a bug of the FIFO always retaining the last character received, and only delivering prior characters to my RX stream buffer. I set RXWATER back to zero, and now the driver does exactly what I expect it to, i.e. generate an interrupt on the first character received. I certainly consider this "proper operation".

The underline/bold text above should be removed from the documentation.

Re: RT1050 - LPUART RXWATER documentation error

victorjimenez — Tue, 14 May 2019 21:25:12 GMT

Hello David,

When Rx FIFO is enabled (FIFO[RXFE] = 1) and RXWATER = 0, then an interrupt/dma request would be triggered when receiving one dataword. But this is like having a FIFO with depth = 1. It is not how the RXWATER functionality is intended to be used. In such case, the Rx FIFO should be disabled to get an interrupt/dma request with every character received.

Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Re: RT1050 - LPUART RXWATER documentation error

dmarks_ls — Mon, 20 May 2019 19:13:22 GMT

Hi Victor,

Honestly, your reply doesn't make any sense to me. A FIFO is a hardware buffer, nothing more. It allows the UART receiver to store more than 1 byte/word of data before an overflow occurs, and safeguards against the condition where the CPU may be busy servicing other higher-priority interrupts and cannot grab the first character before the second character arrives. Yes, if one allows the FIFO to fill up before servicing the interrupt, you do achieve lower ISR overhead. But in the types of applications I deal with (e.g. Modbus master/slave), I cannot think of any case where I would not want to be notified immediately when a single character arrives.

My assertion still stands: the statement in the Reference Manual that RXWATER "must be greater than 0" for "proper operation" is factually incorrect. I have the FIFO enabled and RXWATER set to zero, and the UART operates properly for my application. Disabling the FIFO is pointless; it simply increases the (admittedly small) probability that the UART might drop a character if the CPU is busy in other interrupts or critical sections while high-bitrate data is arriving.

Anyway, I've made my case. You can choose to fix the Reference Manual if you want. Have a good day.

David R.

Re: RT1050 - LPUART RXWATER documentation error

victorjimenez — Wed, 22 May 2019 15:21:42 GMT

Hello David,

Thanks for your feedback. I will pass this information to the documentation team.

Best Regards,

Victor

Re: RT1050 - LPUART RXWATER documentation error

victorjimenez — Fri, 24 May 2019 16:22:48 GMT

Hello David,

I just got the confirmation from the documentation team that this statement is wrong and it will be fixed in future releases of the RM.

Thanks again for your feedback!

Best regards,

Victor