[U-Boot] RFC: i.MX UART failures with baud-rate mis-match

We've identified an issue with i.MX UARTs which causes an infinite stream of input characters when certain input characters with an incorrect baud rate are received.
The details and a couple of ways to reproduce are in this thread on i.MX Community: https://community.freescale.com/message/403254
We'd like to get some feedback from other users of i.MX to see whether the problem exists on especially i.MX51 and i.MX3x.
The easiest way to reproduce the problem is to apply patch 1 in the series, change a serial console to 19200, and send a lower-case 'b' to the serial port at 115200 baud:
U-Boot > setenv baudrate 19200 ## Switch baudrate to 19200 bps and press ENTER ...
... hit a 'b' at 115200 and you should see a spew of garbage.
... hit an 'a' and the spew should stop.
This has been repeated on i.MX6Q, i.MX6S and i.MX53-based boards.
Patch 2 of 2 should resolve the issue.

This patch allows testing of patch 2/2 in the series by forcing bytes read from the i.MX serial port to be printable.
Without this, it's very hard to tell that a series of in-bound '\xff' characters are being produced, because they'll be silently ignored.
Note that this is only submitted for testing.
Signed-off-by: Eric Nelson eric.nelson@boundarydevices.com --- drivers/serial/serial_mxc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c index 56bee55..ef308dc 100644 --- a/drivers/serial/serial_mxc.c +++ b/drivers/serial/serial_mxc.c @@ -145,9 +145,13 @@ static void mxc_serial_setbrg(void)
static int mxc_serial_getc(void) { + unsigned char rx; while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY) WATCHDOG_RESET(); - return (__REG(UART_PHYS + URXD) & URXD_RX_DATA); /* mask out status from upper word */ + rx = (__REG(UART_PHYS + URXD) & URXD_RX_DATA); /* mask out status from upper word */ + if (0x80 <= rx) + rx = '?'; + return rx; }
static void mxc_serial_putc(const char c)

Hi all,
On 05/14/2014 11:04 AM, Eric Nelson wrote:
This patch allows testing of patch 2/2 in the series by forcing bytes read from the i.MX serial port to be printable.
Without this, it's very hard to tell that a series of in-bound '\xff' characters are being produced, because they'll be silently ignored.
An even easier test is to use stty at a Linux shell:
# stty -F /dev/ttymxc1 19200
And then enter a 'b' at 115200.

Bit 7 of UCR3 is described in the i.MX3x/i.MX5x/i.MX6x reference manuals as follows:
Autobaud Detection Not Improved-. Disables new features of autobaud detection (See Baud Rate Automatic Detection Protocol, for more details).
0 Autobaud detection new features selected 1 Keep old autobaud detection mechanism
On at least i.MX6DQ, i.MX6DLS and i.MX53, the "new features" occasionally cause the receiver to get out of sync and continuously produce received characters of '\xff'.
This patch disables the "new feature" on all boards, since there's no support for auto-baud in U-Boot on any of them.
More details are available in this post on i.MX Community: https://community.freescale.com/message/403254
Signed-off-by: Eric Nelson eric.nelson@boundarydevices.com --- drivers/serial/serial_mxc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c index ef308dc..0e24828 100644 --- a/drivers/serial/serial_mxc.c +++ b/drivers/serial/serial_mxc.c @@ -77,7 +77,7 @@ #define UCR3_DSR (1<<10) /* Data set ready */ #define UCR3_DCD (1<<9) /* Data carrier detect */ #define UCR3_RI (1<<8) /* Ring indicator */ -#define UCR3_TIMEOUTEN (1<<7) /* Timeout interrupt enable */ +#define UCR3_ADNIMP (1<<7) /* Autobaud Detection Not Improved */ #define UCR3_RXDSEN (1<<6) /* Receive status interrupt enable */ #define UCR3_AIRINTEN (1<<5) /* Async IR wake interrupt enable */ #define UCR3_AWAKEN (1<<4) /* Async wake interrupt enable */ @@ -190,7 +190,7 @@ static int mxc_serial_init(void)
while (!(__REG(UART_PHYS + UCR2) & UCR2_SRST));
- __REG(UART_PHYS + UCR3) = 0x0704; + __REG(UART_PHYS + UCR3) = 0x0704 | UCR3_ADNIMP; __REG(UART_PHYS + UCR4) = 0x8000; __REG(UART_PHYS + UESC) = 0x002b; __REG(UART_PHYS + UTIM) = 0x0;

On Wed, May 14, 2014 at 3:04 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
Bit 7 of UCR3 is described in the i.MX3x/i.MX5x/i.MX6x reference manuals as follows:
Autobaud Detection Not Improved-. Disables new features of autobaud detection (See Baud Rate Automatic Detection Protocol, for more details). 0 Autobaud detection new features selected 1 Keep old autobaud detection mechanism
On at least i.MX6DQ, i.MX6DLS and i.MX53, the "new features" occasionally cause the receiver to get out of sync and continuously produce received characters of '\xff'.
This patch disables the "new feature" on all boards, since there's no support for auto-baud in U-Boot on any of them.
More details are available in this post on i.MX Community: https://community.freescale.com/message/403254
Signed-off-by: Eric Nelson eric.nelson@boundarydevices.com
Good job, Eric!
I was able to test it on mx6 and mx53 boards:
Tested-by: Fabio Estevam fabio.estevam@freescale.com

Thanks Fabio,
On 05/14/2014 04:36 PM, Fabio Estevam wrote:
On Wed, May 14, 2014 at 3:04 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
Bit 7 of UCR3 is described in the i.MX3x/i.MX5x/i.MX6x reference manuals as follows:
Autobaud Detection Not Improved-. Disables new features of autobaud detection (See Baud Rate Automatic Detection Protocol, for more details). 0 Autobaud detection new features selected 1 Keep old autobaud detection mechanism
On at least i.MX6DQ, i.MX6DLS and i.MX53, the "new features" occasionally cause the receiver to get out of sync and continuously produce received characters of '\xff'.
This patch disables the "new feature" on all boards, since there's no support for auto-baud in U-Boot on any of them.
More details are available in this post on i.MX Community: https://community.freescale.com/message/403254
Signed-off-by: Eric Nelson eric.nelson@boundarydevices.com
Good job, Eric!
I was able to test it on mx6 and mx53 boards:
Tested-by: Fabio Estevam fabio.estevam@freescale.com
Since you've dug through all of the reference manuals, I'll re-send Patch 2 without the RFC.
Regards,
Eric
participants (2)
-
Eric Nelson
-
Fabio Estevam