IMX6 UART Receive Continuous 0xFF

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX6 UART Receive Continuous 0xFF

Jump to solution
5,311 Views
markwilliams
Senior Contributor I

Hi,

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").

Thanks, Mark

Labels (2)
1 Solution
5,082 Views
markwilliams
Senior Contributor I

Ok so I seem to have been able to fix this now through trial and error!

I have ADNIMP set in UCR3 but this would still lock up.

So I enabled ADBR in UCR1 then on the next line disabled the ADBR by clearing it.

Now it no longer locks up and I do not need automatic baud rate enabling. I do get messages from our BSP to do with error frames now and break detect but you would expect that at incorrect baud rate, not lock up.

It would appear that setting and clearing ADBR somehow resets this issue. If you are having this problem try setting and clearing it in your init code.

YuriMuhin_ng‌ this might be worth noting.

View solution in original post

7 Replies
5,083 Views
markwilliams
Senior Contributor I

Ok so I seem to have been able to fix this now through trial and error!

I have ADNIMP set in UCR3 but this would still lock up.

So I enabled ADBR in UCR1 then on the next line disabled the ADBR by clearing it.

Now it no longer locks up and I do not need automatic baud rate enabling. I do get messages from our BSP to do with error frames now and break detect but you would expect that at incorrect baud rate, not lock up.

It would appear that setting and clearing ADBR somehow resets this issue. If you are having this problem try setting and clearing it in your init code.

YuriMuhin_ng‌ this might be worth noting.

4,269 Views
smanni
Contributor I

Hi Mark,

I'm facing the same issue on linux 4.1.15 but I'm not able to fix it setting/resetting ADBR in UCR1. You talked about "init code", do you mean the set/reset is invoked just once when the uart is open or everytime you detect the interrupts storm?

At the moment I'm able to break the interrupts storm just invoking a software reset (SRST in UC3) as advised here https://community.nxp.com/t5/i-MX-Processors/i-MX6-infinite-loop-in-uart-driver-rx-interrupt/m-p/626...

Thanks,

Stefano

0 Kudos
5,084 Views
kimweller
Contributor I

We encountered the same issue on a i.MX 6 dual-lite UART communicating on a RS-485 bus running Linux kernel 4.12. Is Mark's solution to enable ADRB in UCR1 then disable ADBR by clearing it the correct solution for resolving this problem?

0 Kudos
5,084 Views
Yuri
NXP Employee
NXP Employee

kimweller 

Hello,

    We have not tested the Mark Williams approach. But customers are free to use it. 

Regards,

Yuri.

0 Kudos
5,084 Views
markwilliams
Senior Contributor I

From further testing if I also enable auto-baud by setting ADBR to 1 then I do not get the continuous lock-up issue.

So it would seem that with auto-baud disabled (ADBR=0) then when the UART receives a char with incorrect baud rate it can lock up receiving continuous 0xFF with nothing on the line.

The thing is, I don't want to use auto-baud rate. The OS specifies the baud rate when the com port opens.

I guess eventually an 0x41 or 0x61 will be received and stop the auto-bauding. Perhaps on com open I can turn off auto-baud and on com close turn it on again?

It really seems like something that should be in the errata - if not using auto-baud lock-ups can occur if incorrect baud rate data received.

Can NXP support any further here (or anyone else who has fixed this without using autobaud)? Do I need to raise a support ticket?

Mark

0 Kudos
5,084 Views
Yuri
NXP Employee
NXP Employee

Hello,

    The recent considerations regarding the issue were concerned hardware options - this helped.
Please check Your current schematic design - if it  has recommended bypass/decoupling capacitors

on the power rail(s), which feeds the pins, used as UART.
   Remove any series resistors in UART data lines in order to avoid problems while switching  different

UART frequencies.

Regards,

Yuri.

0 Kudos
5,084 Views
markwilliams
Senior Contributor I

Thank you for your reply but I am now not sure of NXP stance on this. In other posts it is suggested that this behaviour is expected and if you violate timings (use wrong baud rate) NXP cannot be responsible for the hardware going crazy.

Now it is suggested that it is potentially the board design at fault. We have adequate decoupling as per design guidelines. I understand that you must see a fair few issues where board design is less than adequate but this has affected a fair few people based on the forum posts using different boards. But always good to verify whether silicon or board design.

But this seems purely because the internal UART module cannot accept incorrect timing data. I can send characters at the matching rate no problems, different rate locks up. The fact that the RX line is steady but no amount of reading of the RX buffer it keeps the RX interrupt triggered shows some internal problem once in this state.

Some found that changing ADNIMP fixed it. So appeared to suggest that the automatic baud rate timing logic was getting confused. This ended up a patch in Linux OS.

Has the reason for this been investigated at NXP in terms of the silicon design?

Mark