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):
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.
Solved! Go to Solution.
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
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.
-------------------------------------------------------------------------------
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.
Hello David,
Thanks for your feedback. I will pass this information to the documentation team.
Best Regards,
Victor
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