[OMAP4430, Kernel 3.0, Android ICS]: Missing data in UART0 (Rx)

Abhishek,

Does the issue happen always or after the Tablet goes to suspend?  Can you please explain more about the missing data issue?

I don't know specifically about the missing bytes, but one place to check is /arch/arm/mach-omap2/omap_hwmod_44xx_data.c.  Especially make sure that the flags are set correctly for your UART.  Also check the initialization in /arch/arm/mach-omap2/board-44xx-serial.c;  I assume you have already done that.  (In kernel 3.0, this takes the place of the omap_serial_platform_data defined in the board file in kernel 2.6.35.)

Regards,

Gina

Hi Gina,

Thanks for the response.  The issue happens always and is not related to tablet suspend/resume.

Details on missing data:

The component connected to UART0 is supposed to send data in 7 bytes packets. There is a definitive way to identify the start byte for a packet (MSB is always 1). For rest of the bytes MSB is always 0 and they contain variable data. In ideal scenario (and this is what happens on Gingerbread image - kernel 2.6.35), Start Byte with MSB  1 should be received, followed by 6 more bytes of data with MSB 0 and then Start Byte of next packet and so on... However, with ICS, I am observing that most of the times I receive less than 6 bytes between the two Start Bytes. Sometimes, I get two or more consecutive Start Bytes.

There are overrun errors observed but these are not related to the packets being complete or incomplete. I get a proper 7 byte packet even after overrun errors and incomplete packets even when there are no overrun errors.

I compared the omap_hwmod_44xx_data.c file for uart initialisation values between Kernel 2.6.35 and 3.0 (since the same component works fine with kernel 2.6.35) and it looks very similar. I see only following differences which I guess are valid:

1. omap_hwmod_class_sysconfig.idlemodes has extra flag SIDLE_SMART_WKUP in kernel 3.0

2. omap_hwmod.prcm.omap4 has extra member - context_reg in kernel 3.0

I did not find board-44xx-serial.c file in the repository. We downloaded the kernel source as mentioned in "L27.IS.2.M1 OMAP4 Icecream Sandwich Release Notes". However, we use the new API omap_serial_init_port_pads() to initialise all the serial ports and provide them the "omap_device_pad" data and "omap_uart_port_info" from our board file. I had changed the "omap_uart_port_info" for UART0 from "blaze_uart_info_uncon" to "blaze_uart_info" to make it work.

Please let me know if more info is required on any of the above.

regards,

abhishek

Abhishek,

board-44xx-serial.c was created by this patch: http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=c33595f06c9ea1bc335a87ba5b7fc6380ddd36d6  They just broke the board file into separate files for clarity, but the content is the same, so it should not matter.

I didn't realize that you were using the L27.IS.2.M1 release.  There are several more recent releases available, namely 4AI.1.4: http://omappedia.org/wiki/4AI.1.4_OMAP4_Icecream_Sandwich_Release_Notes  

I don't know that moving to 4AI.1.4 will necessarily solve this issue with dropped UART packets, but you may want to move to this release to take advantage of other fixes anyway.

Do you see the same issue on multiple HW?  Does your Gingerbread image work fine on this exact HW set?  Please share the logs for the overrun errors that you are getting, as this may be related.  Are you sure that the packets are being dropped, rather than being corrupted?

Regards,

Gina

Abhishek;

In a way of comment, not meant to disrupt current debugging, some points could not apply since previous kernel works.

some questions,

1. Could you share both sides serial port configurations? In initial post you mentioned that connected device is 7 bits data, and mentioned in latest post that you are getting 6 bits from the connected device this most of times between 2 start bits, it could be a mismatch between Blaze Tablet and connected device, one working at 8 bits and other a 7 bits, or it is both configured to use 8 bits but MSB is always set to one?

2. Can you mention about if your connected device is using HW flow control? In case it is, are you using proper cable connections? or either case using a null modem configuration? check no false contact is happening? sometimes with self-made null modem cables incorrect soldering introduces noises? or incorrect configuration makes false data, that must not be because using previous kernel works ok.

3. A second case could be one device using a timer with incorrect or displaced time frame, lets say that clock source is not exact and that is why of bits displacement, is it happening in a harmonic way? if you capture received bytes in a file 6-bit data happens at the same distance between each other? you can check periods using a oscilloscope for both TX lines/pins when transmitting all ones or try TX 1-0-1-0-1-0-1-0. (next line is not be the case because is for BeagleBoard but only like reference http://code.google.com/p/beagleboard/issues/detail?id=22, if this case then it could be HW or SW issue at any side, that must not be HW since previous kernel and same HW works ok).

Hi Gina,

As suggested I downloaded the kernel as per 4AI.1.4 OMAP ICS Release Notes and back ported the changes related to the serial driver stack into the existing source code. In the latest kernel, in file omap_hwmod_44xx_data.c there is a UART related change where "omap_hwmod.flags" is set to "HWMOD_SWSUP_SIDLE" for UART0. With this change I observe that the UART0 does not work. I am in process of porting other changes from 4AI.1.4 kernel to L27.IS.2.M1 kernel and see if this change has any dependencies that I failed to merge.

Answers to your other queries:

- I see the same issue on multiple tablets I have tried.

- The GingerBread image works fine on exactly the same setup.

- As per my observations the bytes in the packets are getting dropped (and thus corrupting the packet). The bytes themselves are not getting corrupted.

Logs:

Kernel 3.0.8 (ICS)

UART0: 0xa0 0x65 0x5 0x78 0x0 0x20
UART0: 0xa1 0x65 0x5 0x78 0x22
UART0: 0xa1 0x64 0x5 0x78 0x27 0x6a
UART0: 0xa1 0x62 0x5 0x79 0x1c 0x2a
UART0: 0xa1(OE = 1) 0x61(OE = 2) 0x5(OE = 3) 0x7b(OE = 4) 0x2b(OE = 5) 0x5a(OE = 6)
UART0: 0xa1(OE = 7) 0x5f 0x5 0x7d 0x20 0x6a
UART0: 0xa1 0x5e 0x5 0x7d 0x22 0xa
UART0: 0xa1 0x5b 0x5 0x7d 0x16 0x6a
UART0: 0xa1 0x5b 0x5 0x7d 0x1e 0x72
UART0: 0xa1 0x5b 0x5 0x7d 0xc 0x72
UART0: 0xa1 0x5a 0x5 0x7d 0x6b 0x71
UART0: 0xa0 0x5a 0x5 0x7e 0x0 0x68
UART0: 0xa0 0x5a 0x5 0x7e 0x0 0x68
UART0: 0xa0 0x5a 0x5 0x7e 0x0 0x68
UART0: 0xa0 0x5a 0x5
UART0: 0xa0 0x7a
UART0: 0xa0 0x6a
UART0: 0xa0
UART0: 0xa0 0x30
UART0: 0xe0 0x30 0x5 0x59 0x0 0x70

Please note that I get max 6 bytes per packet instead of expected 7. OE denotes overrun error with the count.

Below is similar log  from GB image (Kernel 2.6.35 ) for reference

UART0: 0xa0 0x13 0x3d 0xa 0x7c 0x0 0x28
UART0: 0xa0 0x13 0x3d 0xa 0x7c 0x0 0x28
UART0: 0xa0 0x13 0x42 0xa 0x7c 0x0 0x68
UART0: 0xa0 0x13 0x44 0xa 0x7c 0x0 0x68
UART0: 0xa1 0x13 0x44 0xa 0x75 0x1b 0x72
UART0: 0xa1 0x13 0x42 0xa 0x78 0x3e 0xb
UART0: 0xa1 0x13 0x40 0xa 0x78 0x6a 0x2b
UART0: 0xa1 0x13 0x3e 0xa 0x78 0x74 0x4b
UART0: 0xa1 0x13 0x3d 0xa 0x78 0x1 0x6c
UART0: 0xa1 0x13 0x3d 0xa 0x78 0x26 0xc
UART0: 0xa1 0x13 0x3d 0xa(OE = 1) 0x78(OE = 2) 0x21(OE = 3) 0xc(OE = 4)
UART0: 0xa1 0x13(OE = 5) 0x3d(OE = 6) 0xa 0x78(OE = 7) 0x5(OE = 8) 0xc(OE = 9)
UART0: 0xa1(OE = 10) 0x13 0x3d 0xa 0x78 0x8 0xc
UART0: 0xa1 0x13 0x3d 0xa 0x78 0x3 0xc
UART0: 0xa1 0x13 0x3d 0xa 0x78 0x3b 0xb
UART0: 0xa1 0x13 0x3d 0xa 0x78 0x47 0xa
UART0: 0xa0 0x13 0x3d 0xa 0x78 0x0 0x8
UART0: 0xa0 0x13 0x43 0xa 0x78 0x0 0x28
UART0: 0xe0 0x60 0x21 0x52 0x1f 0x0 0x28

Please note that I consistently get 7 bytes packets.

regards,

abhishek

Hi Manuel,

1. Serial port configurations:

Component side (as per the datasheet): 19.2kbps, 1-bit start, 8bits data, 1-bit stop, parity none
OMAP UART0 configuration: 19.2kbps, 8bits data, 1-bit stop, parity none

Termios flag settings at OMAP end:

termios.c_cflag &= ~CSIZE;
termios.c_cflag |= CS8;
termios.c_cflag &= ~PARENB;
termios.c_cflag &= ~CSTOPB;
termios.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON);
termios.c_cflag |= CLOCAL | CREAD;
termios.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);

The same settings are used in GingerBread and it works fine.

2. We are not using HW flow control.

3. I have posted UART logs in another post to Gina in the same thread. I do not think there is any pattern to the missing bytes.

One correction: In my earlier post, I mentioned that the component sends data in packets of 7 bytes and not bits. So, the first byte of every packet has MSb set to 1. Rest all other bytes in the packet have MSb 0.

regards,

abhishek

Abhishek,

Unfortunately I don't see what could be causing your issue.  Have you completed the merge to the 4AI.1.4 release?  Do you still see the same behavior?

Thank you,

Gina

Hi Gina,

Apologies for the delay. We finally ported our code base to ICS 4AI.1.4 release. The UART1 does not work at all if .flag = HWMOD_SWSUP_SIDLE is specified for omap44xx_uart1_hwmod in file omap_hwmod_44xx_data.c.  When I disable it, the UART works but with the same behaviour as before. Any further suggestions?

regards,

abhishek

Abhishek,

I am surprised that UART1 does not work at all if HWMOD_SWSUP_SIDLE is set.  This was added by the patch: http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5e7257679cadf9a4acc340c8e8c1198c4a563d82  I will check this issue some more internally.

Regards,

Gina