MBDT LPUART problem

[Alfredo_Rubio]

I'm planning to develop a proprietary serial protocol in a S32K144 proyect.

I want to go the MDBT way. With this propose I’m starting with the LPUART echo example.

If sent character by character through a terminal, it’s works properly. But the problem occurs when I send a longer string (More than a character). In that moment a lost most of the characters. I’ve tried reducing the sample time and even reducing the baud rate up to 4800BPS. Under this condition the example behavior improves but I’m still losing most of the bytes.

Could you please give me some advice on this problem?

Thanks, you in advance.

[Dennis74]

Don't forget that even if you don't call the LPUART_ReadByte() function, the characters entered to your UART port has saved into UART buffer and after you call ReadByte it first reads the previous entered characters. If you overcommit to UART port and fill its buffer, it sets the Overrun flag and refuses to take more input characters from that port.

The thing you should do is, clearing the Overrun flag after it is anyhow set. It would be better if you check overrun flag and if it is set, clear it by yourself manually.

if(kLPUART_RxOverrunFlag & LPUART_GetStatusFlags(ESP_UART))
{LPUART_ClearStatusFlags(ESP_UART,kLPUART_RxOverrunFlag);}

You can check for this flag and clear it every before you want to read a data from your UART.

[Peter451]

This suggests the distinct possibility that at some point in the past you failed to claim data before it would have been overwritten, setting the overrun flag. But if you also had a delayed response to the original receive data interrupt, you could have read the original data without awareness of the problem. However, if you did so, and left the overrun flag on, that would be the last data you ever received.

It seems like there are at least three things you need to do:

1. Fully implement or fully ignore the optional FIFO mode

2. Check the overrun flag, clear it to see if it makes a difference, but also find a way to indicate (set a sticky volatile software flag, toggle a GPIO watched by a scope in one time trigger mode, whatever) to indicate that a problem has occurred, so that you can take steps to investigate that.

3. Analyze and test your program overall for design faults which might yield to failure to respond to serial data quickly enough. This could include things like toggling a GPIO in the ISR and watching that and the serial data line on a scope, putting timer checks into the code, and auditing all other ISRs and any foreground options which must disable interrupts. Also try stripping your program down until you simply have something that receives and echos characters and experiment with that, both hitting keys one at a time in a terminal program, and having a program inject strings at a rate which keeps the serial line 100% busy.

Also keep in mind that while break point debugging can be very powerful, with any program that must respond to external events, it is quite likely that operation will no longer be normal after the first time the breakpoint is hit, so to approach a problem in that way you often need to design tests which end at the point where the breakpoint is hit and you analyze only the state collected up to that point. Sometimes this means you need to an an "if" condition so that you can put a breakpoint inside of it.