imx53 UART5 RX problem

[MarkRoy]

Hello folks,

I'm using the 11.09 Linux BSP   (2.6.35.3 kernel) on a custom i.mx53 board.  

I have UART5_RXD_MUX and UART5_TXD_MUX connected on  CSIO_DAT15 (alt 2) and CSIO_DAT14 (alt 2) respectively.  I have added in the list of pads for the board  MX53_PAD_CSI0_DAT15__UART5_RXD_MUX  and MX53_PAD_CSI0_DAT14__UART5_TXD_MUX for iomuxing.

I have looped back the RX and TX pins  with a jumper wire on the board so that anything sent on TX should be received on RX.  If I connect my scope to the RXD pin and transmit some data, I can see it transmitting just fine.   However, the imx53 does not seem to receive anything.

I have modified arch/arm/mach-mx5/serial.c and arch/arm/mach-mx5/serial.h so that all of the UARTS have the same settings.   The other UARTS seem to be working fine and I have configured them the same way.

I have also verified that I have the right pin, U2 of the imx53 that I am using on my board.   I also dont believe that the pin is damaged because I have two boards and they both show the identical problem.

Please let me know if anybody has any ideas or suggestions as to why the RXD might not be working on UART5.

Regards,
Mark Roy

[MarkRoy · Accepted solution]

I've found and fixed the problem.

There are several mistakes in arch/arm/plat-mxc/include/mach/iomux-mx53.h

There is a mistake on almost every TXD_MUX define for all five UARTS such as this:

#define _MX53_PAD_PATA_DIOW_UART1_TXD_MUX IOMUX_PAD(0x5F0, 0x270, 3, 0x878, 2, 0)

In this line, it lists the offset 0x878 for the SELECT_INPUT with a value of 2.  The 0x878 offset corresponds to the IOMUXC_UART1_IPP_UART_RXD_MUX_SELECT_INPUT register and assigns it a value of 2 which selects PATA_DIOW for mode ALT3.     So when it configures the iomuxing for the TXD line it incorrectly sets the RXD_MUX_SELECT_INPUT to the wrong pin, ensuring that any data on the proper pin will not be received.  

The reason that my code works for some UARTs but not others was that in my list of pads to setup, I put the RXD pad before TXD for UARTS 3,4 and 5.   For UARTS 1 and 2, they worked because when setting up the RXD pin, it would overwrite the incorrect value from when it setup the TXD pin.

To fix it properly, I have modified my version of   arch/arm/plat-mxc/include/mach/iomux-mx53.h

So, for the example above, the #define should have been:

#define _MX53_PAD_PATA_DIOW_UART1_TXD_MUX IOMUX_PAD(0x5F0, 0x270, 3, 0x0, 0, 0) 

With no SELECT_INPUT_OFS so that it does not write into the RXD select input.  I'm not sure why the RXD has this extra level of muxing when the TXD does not.

This change needs to be duplicated for every TXD_MUX  #define in the iomux-mx53.h  (for each ALT option, there are 2 or 3 options per UART).

Cheers.

[maheshmahadeva1]

Thanks for pointing the issue and the fix. It is available at the below git repository:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain

[fabio_estevam]

Mark,

Thanks for reporting it.

I have just taken a look at the mainline code and I see:

git.kernel.org - linux/kernel/git/torvalds/linux.git/blob - drivers/pinctrl/pinctrl-imx53.c

IMX_PIN_REG(MX53_PAD_PATA_DIOW, 0x5F0, 0x270, 3, 0x000, 0), /* MX53_PAD_PATA_DIOW__UART1_TXD_MUX */

,which matches your proposed definition.

So it looks like these are defined correctly in the version from kernel.org.

Regards,

Fabio Estevam

[RodBorras]

Mark,

That is very impressive. Thank you!

I apologize for the mistakes in our code. I will inform the BSP team so it can be fixed.

Regards,

Rod.

[MarkRoy]

I've been checking clocking and also digging through the serial driver and for the life of me I cant figure out what's wrong.

I've checked the IOMUX configuration countless times and verified each of these configuration registers from the reference manual.  They should all be correct as I have defined in my board file.   I have also verified the daisychain configuration.

I've checked clocking and the clocks all seem to be registered and running since I can transmit fine on all UARTS.

I added a debug line to the mxcuart_int  ISR in the mxc_uart.c driver and it cr1, sr1, and sr2 seem to be correct.   In cr1  RRDYEN is set, so it should be generating interrupts on receive, but it seems no such interrupt is generated.   I have my oscilloscope connected directly to pin U2 (CSI0_DAT15) and the on-chip pull up is enabled on boot and the bus floats to 1.8V,  transmitting my data to it through a level translator I can see very clear characters being sent on my oscilloscope.

I'll keep digging around, hopefully the solution isnt for me to just abandon UARTs 4/5.

[RodBorras]

Mark,

In situations like these, it is sometimes easier to figure this out in bare-metal code, just in case Linux is doing something you are not aware of.

Have you tried the OBDS (On Board Diagnostic Suite) before? It is very simple bare-metal code with tests for most peripherals.

You can find it here: i.MX534 Product Summary Page

under the  Lab & Test Software tab.

Regards,

Rod.

[MarkRoy]

I have already changed the macros in iomux-mx53.h

I'll look into the clocks again for UART5, but I think if it were the case of incorrect clocking, then the UART5 TX should not work.

[edit] I just checked the clocks and they are correctly registered.  When I boot, all 5 uarts are found and populated.   All UARTS transmit function works fine.

I'm going to try jumpering the TX / RX on UART4 to see if it is working correctly, or if it is just uart5 that is not working correctly.

[edit2] Just confirmed that UART4 RX is also not working.  Maybe there is another issue with the clocking other than registration? 

Mark

[RodBorras]

Mark,

Take a look at these 2 other entries:

Enabling Uarts 4 & 5 on i.MX53 QSB

This one shows the need to set up the clock for UART5.

UART4 not responding but UART2 does

Take a look at the comment on the macros.

Regards,

Rod.