We have been tracking an issue with an iMX6S processor using a Windows Embedded Compact 7 BSP where the UART gets into a state where it continuously receives 0xFF even with no activity on the line. Once triggered it will repeatedly hit the RX ISR even if you read the byte out that it thinks it got.
After tracking this issue and searching it would seem this is a known issue with the iMX6 processors - oddly it hasn't reached the errata. There are a number of posts on this and they suggest setting a bit ADNIMP in UCR3 to clear the issue. But this doesn't appear to be working for me.
I saw responses from NXP suggesting the following (in i.MX6 infinite loop in uart driver(rx interrupt)):
"Being completely accurate, we cannot guarantee proper UART operations, when UART specs are violated.
The short start bit period must not be less, than 7/16 of bit time slot" - Yuri Muhin NXP
"this is a feature of UART" - Yuri Muhin NXP (in response so someone suggesting it could happen very easily with RS485
In our case we have something connected to the serial port sending out data at 115200 before the OS is loaded and opens the com port. Until then the UART has 9600 baud. So when it receives the 115200 baud byte when set internally at 9600 rather than flag an error it loops endlessly thinking it is receiving 0xFF and locks up.
I can't see how this can be described as intended behaviour, or that because we are sending a byte at the wrong baud rate this sort of lock-up response is somehow acceptable?!
We need to overcome this in our application and ADNIMP doesn't seem to be fixing it at the moment. Has anyone been able to work-around this issue in the processor? We could have different baud items connected, or even see glitches on the UART and if that triggers instability then it certainly warrants it being on the errata or a workaround/fix published (other than "make sure UART only receives the baud rate data it is configured for and that all frame timings are valid").