i.MX UART hardware misbehaves on baudrate mismatch

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX UART hardware misbehaves on baudrate mismatch

Jump to solution
1,818 Views
Senior Contributor I

Dear all,

Now, we have a issue in the product using i.MX6SX.

I searched it in this community, and I found any same issues as follows:

i.MX6 infinite loop in uart driver(rx interrupt) 

i.MX6 UART hardware misbehaves on baudrate mismatch 

It is an issue to continue receiving 0xFF as well as these reports, although there is no data reception.

As shown in the following figure, general UART communication has Start bit and Stop bit.

pastedImage_3.png

When receiving continuous data, can't the UART block for i.MX detect Start-bit and Stop-bit?

Best Regards,

George

0 Kudos
1 Solution
376 Views
NXP Employee
NXP Employee

Hi George,

I found a workaround for this issue.

Here is the change I made:

http://code.bulix.org/eaioxl-320184 

besides this change you also need to pass fsl,automatic-baudrate in the uart2 node:

&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart2>;
fsl,automatic-baudrate;
status = "okay";
};

This change enables automatic baud rate detection and avoids the storm of 0xFF.

Regards,

Fabio Estevam

View solution in original post

23 Replies
373 Views
NXP Employee
NXP Employee

Hi George,

It seems you are using UART1 and the M4 UART in this case, aren't you?

Regards,

Fabio Estevam

0 Kudos
373 Views
Senior Contributor I

Dear FabioEstevam‌,


What then?
You can be reproduced?

BR,
George

0 Kudos
373 Views
NXP Employee
NXP Employee

Hi George,

I was able to reproduce the issue, but I don't have a fix at the moment.

Regards,

Fabio Estevam

0 Kudos
373 Views
NXP Employee
NXP Employee

Hi George,

I noticed that the problem happens when the ttymxc1 terminal is at 115200. If I set it to 9600 then when I type 'a' in this terminal I do see "61" correctly printed on the ttymxc0 terminal. No storm of FF is seen anymore.

Could you please try running the ttymxc1 terminal at 9600 instead? 

Regards,

Fabio Estevam

0 Kudos
373 Views
NXP Employee
NXP Employee

Hi George,

This seems like the problem I fixed a long time ago:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/serial/imx.c?i... 

For some reason this patch does not fix the baudrate mismatch on mx6sx.

I am not sure when I will be able to investigate this issue.

I have also tested this on a 4.16.2 mainline kernel and the problem is still present.

If you want additional assistance, please start a thread explaining the issue at linux-serial@vger.kernel.org and linux-arm-kernel@lists.infradead.org  mailing lists. You can also put on Cc the developers that touched this driver recently.

In order to know who those folks are you can run git log drivers/tty/serial/imx.c and look at the most recent commits.

Regards,

Fabio Estevam

0 Kudos
377 Views
NXP Employee
NXP Employee

Hi George,

I found a workaround for this issue.

Here is the change I made:

http://code.bulix.org/eaioxl-320184 

besides this change you also need to pass fsl,automatic-baudrate in the uart2 node:

&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart2>;
fsl,automatic-baudrate;
status = "okay";
};

This change enables automatic baud rate detection and avoids the storm of 0xFF.

Regards,

Fabio Estevam

View solution in original post

373 Views
Contributor II

Am I right thinking this workaround will not cope with several baudrate changes? (my idea is to start talking to a device using 9600 bauds and properly negotiate a high baudrate if device answers at 9600, before switching to the higher baudrate).

Reading iMX6 datasheet I understand that UCR1_ADBR enables/start baudrate detection, which halts itself when it find the baudrate (by detecting a 'a' or 'A' character). ADET must be reset to start autobauding again. Reading pointed patch, I see ADBR is set within imx serial port startup (initial opening), hence only once if I am not wrong. ADET is never unmodified (default to zero).

I think I crossed this issue at least once (with a 9600 / 460800 bauds switches) on a iMX6ULL processor running Linux kernel v4.9.84, already featuring UCR3 ADNIMP fix (see i.MX6 UART hardware misbehaves on baudrate mismatch). I previously used 9600 / 115200 bauds switches, seeing 0xff during baudrate incoherencies but maybe never storms. When I try to reproduce the issue by forcing 9600 / 460800 baudrate incoherencies, I easily see 0xff chunks too but not storms in my attempts to reproduce my issue catched in logs of a device.

Is there a new well known fix or workaround for those 0xff storms since last update of this thread?

In my case, the 0xff storm catched in logs stopped when the board joined suspend state and things were back fine after the suspend. Is there other very-known cases known to circumvent this issue?

0 Kudos
373 Views
Senior Contributor I

I am also having issues with this. I have tried setting ADNIMP but if I sent bytes at 115200 while the port is set to 9600 I get 0xFF constant RX interrupts.

We have peripherals that can send out at one baud rate before the port is configured and opened.

I don't want to use autobaud.

Did you manage to fix or work around this?

Thanks, Mark

0 Kudos
366 Views
NXP Employee
NXP Employee

Hi Mark and Anthony,

It would be nice if one of you could start a thread about this issue on the kernel mailing list.

To see the relevant list and people to add in Cc, please run:

./scripts/get_maintainer.pl -f drivers/tty/serial/imx.c

Please provide reproduction steps, kernel version, etc in the message there.

0 Kudos
366 Views
NXP Employee
NXP Employee

Also, does this happen with a recent kernel such as 5.4?

0 Kudos
366 Views
Contributor II

I am using linux-fslc, branch 4.9-1.0.x-imx (because default branch 4.9.x+fslc missed PF1550 support when I was working on it around 2018-03), commit 0e674a64b86e (the top one at this time). DMA enabled I guess (at least I did not explicitly disabled it) and SDMA firmware 3.3 is properly loaded during boot.

The issue did not trigger systematically, but occurred within a few days (which is huge within a fleet containing thousands of products). It had been discovered when a 9600->115200 transition has been upgraded to 9600->460800, but not sure it did not exists previously (less often). I have workarounded it in most cases by saving baudrate into peripheral flash but there is still weak cases where I need to change baudrate (like peripheral fw ugrade), for which I am looking for a robust solution.

Switching to a new kernel is not really an option for me I think, since I have not that much time to port my patches, and since products are on the field (an OTA update of the entire kernel would be much more costly than a chirurgical OTA update of imx serial module).

0 Kudos
366 Views
Senior Contributor I

I am not using Linux but Windows CE. As it seems to be a problem with UART HW the same would be for bare metal or any other use of the UART.

I managed to resolve the issue by enabling then immediately disabling ADBR (automatic baud rate) during init. Without this step it locks up UART on baud rate mismatch with streaming RX 0xFF. With this enable/disable step it seems to initialise something in the UART that then prevents it. I also have ADNIMP set - I haven't yet tried without.

See my post: https://community.nxp.com/message/1330180 

0 Kudos
373 Views
Contributor II

I finally found an option to save wanted baudrate on my peripheral. Hence it start at 9600, I ask it to join higher baudrate and I ask it to save it. On subsequent starts of this peripheral, it starts discussing directly on my high baudrate and me too, avoiding the issue which only remains on factory side (first 9600->high transition) and during OTA of peripheral firmware.

This is not ideal, actually I hate saving parameters to peripherals flash memory since all starts of this peripheral do not execute the same code path and do not behave exactly the same. I did not found other solutions.

0 Kudos
373 Views
Senior Contributor I

Hi FabioEstevam‌,

In this case, M4 is not started in u-boot.

If you use the dtb file which I attached here, you can use UART2 on linux.

BR,

George

0 Kudos
373 Views
NXP Employee
NXP Employee

Hi George,

Which kernel version are you using?

Please send detailed reproduction steps.

Thanks

0 Kudos
373 Views
Senior Contributor I

Dear FabioEstevam

I am sorry for the delay in my response.

I indicate below how you can reproduce it easily.

Preparation :

  • i.MX6 SoloX sabre is used as H/W.
  • imx-4.1.15-1.0.0_ga is used as BSP.
  • In order to create SD card image, fsl-image-validation is used for a yocto recipe.
  • dtb is created using the dts file attached here.
    • By using this dtb, /dev/ttymxc1 can be used in addition to /dev/ttymxc0.
  • The ttymxc1 is set to 9600bps, and the program which gets character codes is build.
    • It is attached dump_ttymxc1@9600.c
    • dump_ttymxc1@115k.c is only referred to and will not be used here.

 

Reproduce step :

  1. Between PC and SABRE board is connected by the USB virtual COM ports.
  2. Two terminal emulators are started on PC.
    • Both set the terminal speed on PC as 115200-bsp.
  3. linux is booted using created dtb.
  4. login into the terminal whose login prompt can be seen.
  5. And the program(dump_ttymxc1@9600.out) compiled beforehand is run.
  6. Finally "a" is typed only once from ttymxc1 side terminal emulator.
    • You will see 0xFF to the ttymxc0 side terminal emulator forever after this.

We wish to improve this strange condition.
Because, the other company SoC is not so.

Best Regards,

George

0 Kudos
373 Views
NXP Employee
NXP Employee

Geroge,

Could you please try it with a 4.9 kernel instead?

0 Kudos
373 Views
Senior Contributor I

Dear FabioEstevam‌,

I checked using S/W shown below as you say.

However, the condition which outputs 0xFF forever was completely the same.

zImage and dtb which I used are attached.

i.MX6SX-SABRE which you have should also be reproduced.

Best Regards,

George

0 Kudos
373 Views
NXP Employee
NXP Employee

Hi George,

I would like to reproduce this on my mx6sx sdb board.

However it is not clear for me how you are connecting UART2 to the Linux PC. Could you please explain?

0 Kudos
373 Views
Senior Contributor I

Hi FabioEstevam‌,

Yes, two virtual COM ports are connected to my Linux PC with the USB cable.

Best Regards,

George

0 Kudos