Just yuri 1.15 serial#

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'). We need to overcome this in our application and ADNIMP doesn't seem to be fixing it at the moment. 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?! 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.

Just yuri 1.15 serial#

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. ' this is a feature of UART' - YuriВ Muhin NXP (in response so someone suggesting it could happen very easily with RS485 The short start bit period must not be less, than 7/16 of bit time slot' - Yuri Muhin NXP ' Being completely accurate, we cannot guarantee proper UART operations, when UART specs are violated. I saw responses from NXP suggesting the following (in i.MX6 infinite loop in uart driver(rx interrupt)): But this doesn't appear to be working for me. There are a number of posts on this and they suggest setting a bit ADNIMP in UCR3 to clear the issue. Once triggered it will repeatedly hit the RX ISR even if you read the byte out that it thinks it got.ДЄfter tracking this issue and searching it would seem this is a known issue with the iMX6 processors - oddly it hasn't reached the errata. 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.