TM4C123BE6PM: UARTCTL.RXE bit operation and a corruption of RX data

Pardon - note that I'm an 'outsider' - yet have experienced a (somewhat) similar issue w/in an RS485 network.

While 'inexpert' w/this vendor's MCU's 'fine details' - yet perhaps these questions will, 'Aid the vendor's response & diagnosis:

• you note receiving 'unexpected bytes' - did you (really) mean 'bytes?'    In our case - the RS485 transceiver (occasionally) glitched - but (only) a single 'illegal byte' resulted.    If indeed you're noting (multiple) bytes - that's a more serious condition - and should be 'easier' to diagnose.
• is the RS485 bus (MCU end) properly terminated?    (that's a known cause of periodic glitching)
• are other power or RS485 bus 'disturbances' (possibly) being introduced - which may cause/contribute to such glitching?
• as always - does this condition occur across (multiple) boards?    Single board anomalies are the 'bane' of diagnostics.
• while unusual - do check that 'all RS485 bus participants' have their baud rates equalized - & that each meets the minimum specification requirement
• many such RS485 transceivers 'require' bypass caps and adequate power traces along w/'maintaining the RS485's differential signal 'balance'
• differential 'bus signal pair' should AVOID adjacent parallel conductor runs & especially - Noise and/or Power Sources - coming into 'near/close' contact.

Following these guidelines has enabled (multiple) of our 'Multi-Vendor - MCU-RS485 transceiver implementations' - to long succeed - w/out incident.   

May I note that I'm 'not in agreement' w/customer's 'UARTCTL.RXE bit' (management) - as that is a 'symptom' - NOT a 'cause' - of the noted issue...   (and as you've noted - has itself - introduced new (likely even more complex) issues!)

Hello Nambu-san,

Hideaki Nambu said:

My customer concerns that Setting/Clearing UARTCTL.RXE bit brings a change of U6RX pin impedance or voltage.

Do you agree this? If you agree, could you please how much the impedance and voltage changes ?

I do not agree with this, this is just a register enabling whether or not the data will be stored in the device. It should impact the hardware at all because it is not turning off the pin at all.

This essentially proven by this statement: "If the UART is disabled in the middle of a receive, it completes the current character before stopping."

If the pin impedance or voltage would be affected by disabling RXE then it couldn't finish receiving data.

Hideaki Nambu said:

Could you please advise how long it takes, from setting UARTCTL.RXE bit to get ready to receive data ?

Unfortunately I have not found any specification for this. In a typical application the bit is always enabled in the UART, and it does not look like a specification was put in place for toggling the bit. I would imagine it would only take a few clock cycles to take effect, but the start bit would need to arrive at least after the register write is done. If they are in a situation where it is being very tightly timed to turn it on where that could even be an issue then I am not sure this is the right approach to solve the issue.

cb1's ideas on how to debug the root cause (unexpected bytes received) should be reviewed as there is no need for this workaround if they can solve the root cause so the unexpected bytes no longer appear.

Hideaki Nambu said:

Could you please advise how long it takes, from clearing UARTCTL.RXE bit to ignore a new byte?

As stated in the DS, if a current byte is being received, then it will conclude reception of it before stopping to receive data. If no bytes are being received, it will stop receiving data once set. The customer should keep in mind that the start bit will precede data, so even getting a start bit would result in that byte being received.