How common is UART RX corruption for the MPC5777m?

[jschloss]

Looking through the errata for the MPC5777m - 0N50N, I noticed e8731 that states received data may be shifted by one bit, or sampled off by one - I tried to do some testing to observe this at different baud rates and clock speeds, but wasn't able to trigger it. I also turned on the suggested 0 parity and parity error check, but haven't had it trip a frame error yet (only 1 day testing so far).

How often does this happen in practice? Is it more common in some configurations than others? Has any one observed it in the wild? Would always using the 16x oversample mode help?

Thanks,

Jacob

[jschloss]

Looking at the errata some more - "This information is available 5 times the LINIBRR[IBR] period of the LIN_CLK before the
completion of the STOP bit reception."

So, if I do not use the RX FIFO, but make sure I read every frame by the 5th bit time of the next frame it should always be intact?

[lukaszadrapa · Accepted solution]

Hi Jacob,

it looks like data about probability of occurring are not available.

The note:

“This information is available 5 times the LINIBRR[IBR] period of the LIN_CLK before the completion of the STOP bit reception.”

… means something different. Let me explain: each bit is sampled 16x by receiver logic. The receiver then uses samples 8, 9 and 10 to distinguish if received bit is logic ‘0’ or logic ‘1’. When receiving the stop bit, data reception completed flag is set in next clock after receiving 10th sample. And here are the 5 clocks – the 5 clocks refer to clock given by LINIBRR[IBR]. This is the time period between setting of data reception completed flag and receiving of whole stop bit (all 16 samples).

Regards,

Lukas

[jschloss]

Ok, that makes sense. Thank you. For anyone interested / FWIW it was running for several days at 25Mbaud, and several days at 115200baud without an observed error. I will be check-summing all incoming data as well so should be fine.