UART4 not responding but UART2 does

[VincentChou1z]

Hi! All,

We add the following lines on mx53_loco.c and create the image.

------------------------

    /* UART2 */
    MX53_PAD_PATA_BUFFER_EN__UART2_RXD_MUX,
    MX53_PAD_PATA_DMARQ__UART2_TXD_MUX,
    /* UART4 */
    MX53_PAD_CSI0_DAT12__UART4_TXD_MUX,
    MX53_PAD_CSI0_DAT13__UART4_RXD_MUX,
-----------------------

We also wire these UART to a port on PC.  Apparently we could open UART2 port with ssh but UART4 does not show any response.  Can anyone tell us what we did wrong to enable UART4?

Vincent

[GregHill]

DeanHuang said:

I'm using LTIB 11.09 and it only have mxc_board_init() in arch/arm/mx53_loco.c . Also, don't have imx53_add_imx_uart() in this function mxc_board_init().

Could you please help me?

I'm sorry -- I used LTIB 11.09, but I used kernel 2.6.38 instead of the default (2.6.35). These files changed substantially between those kernel versions and I don't have it solved for the 2.6.35 version.

As you noticed, it looks like some things are similar between board-mx53_loco.c and mx53_loco.c (mx53_loco_pads array for example). But I don't know where to make changes to enable the uart. I see some interesting things in linux-2.6.35.3/arch/arm/plat-mxs/ and linux-2.6.35.3/arch/arm/plat-mxc/, but I don't know whether either of these is used for the mx53 build.

[DeanHuang]

Hi Grep,

I would like to use UART1 HW control, but I don't have this file board-mx53_loco.c, too.

I'm using LTIB 11.09 and it only have mxc_board_init() in arch/arm/mx53_loco.c . Also, don't have imx53_add_imx_uart() in this function mxc_board_init().

Could you please help me?

[VincentChou1z]

Could you share which ltib version you use?  

[enaud]

hi,

i dont have board-mx53_loco .c in  arch/arm/mach-mx5/.

How activate uart2?

[VincentChou1z]

Hi! Alan and Greg,

Thanks for your help in providing your experience.  I looked into my code and discovered that the code does not require imx53_add_imx_uart because I could not locate any string like this in my BSP09.  However, I do discover the PMIC interrupt does share the same "MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12" in mxc_board_init routine.  I compare the schematic of QSB-R and QSB and discovered that I could remap the interrupt to "MX53_PAD_GPIO_16__GPIO7_11" and my UART4 works just fine now.  I guess this is just one of the bug that the BSP presents to my board.

Nevertheless, thanks you for your help!  My UART4 works now.

Vincent

[GregHill]

Alan, a huge thanks to you for the tip about the defective header file. I was stuck at the same problem -- my I/O worked fine when I set registers manually at the u-boot prompt, but inside Linux, things were not right.

Following are some notes to ease the journey for others who might come along searching for answers to enable additional serial ports on their MX53 loco/QSB:

1. in arch/arm/mach-mx5/board-mx53_loco.c modify the mx53_loco_pads array to add the pad configurations for your UART and remove any other configurations that might conflict for the same pad (add MX53_PAD_CSI0_DAT12__UART4_TXD_MUX and remove MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12 for example, because both use the CSI0_DAT12 pad)
2. in case you want hardware flow control, add in board-mx53_loco.c a struct like so:
   static const struct imxuart_platform_data mx53_loco_uart_data = {
      .flags = IMXUART_HAVE_RTSCTS,
   };
3. in board-mx53_loco.c mx53_loco_board_init(void) function, find the initialization of ttymxc0 (imx53_add_imx_uart(0, NULL);) and add near it the initialization for your new UART, for example I added UART4/ttymxc3:
   imx53_add_imx_uart(3, &mx53_loco_uart_data);
   If you want HW flow control then pass a pointer to the struct from step 2 in the initialization, otherwise you can pass NULL as in the ttymxc0 case.
4. edit arch/arm/plat-mxc/include/mach/iomux-mx53.h as described by Alan above so that the relevant pad definitions have correct offset, register initialization, and MUX_PAD_CTRL() settings.

One other thing to note: my board actually runs 1.8v I/O for UART4, not 3.3v. I had to build a level converter in order to connect the UART with my 3.3v device.

[AlanLevy]

It's going to depend on the reason why UART4 isn't working on your current hardware. You really need to try to find this out, otherwise you could end up with another board iteration that still doesn't work. Try configuring the pins as GPIOs and see if you can read/write them that way. If so it's presumably a configuration issue, if not you need to take a careful look at your hardware.

[VincentChou1z]

Hi!  I have not been able to figure out the problem on my UART4 yet.  Is it better for me to switch to KEY_ROW0/COL0 in my next version of hardware?  I guess it is better to follow what has been tested first.

[AlanLevy]

I haven't checked the macros very carefully so there could be bugs in the macros for CSI0_DAT12/13 that aren't in the macros for KEY_ROW0/COL0, or you could have problems with your hardware. You could try raising a support request with Freescale.

[VincentChou1z]

Hi! Alan, 

Yes!  We do have a level shifter to raise the voltage to the appropriate voltage.  Unfortunately we still could not open UART4 with Putty.  We did turn off hardware flow control though.  I think my case is different from your situation because we use CSI0_DAT12/13 instead of KEY_ROW0/COL0.  Do you think this could be the issue?  

Vincent 

[AlanLevy]

Does your USB to UART cable include an RS232 3.3V level shifter? Also make sure that your terminal emulator has hardware handshaking turned off.

[VincentChou1z]

I did modify the macro in iomux-mx53.h and also keep the same UART2 and UART4 configuration in mx53_loco.c.  After I modify these files, I use Ltib to rebuild the kernel and rootfs.  

After that, I created a bootable Micro-SD card.  I could boot my target board with the SD card and observe the TX and RX level of UART4 are pulled high if I connect the UART4 to a PC with a USB-to-UART cable.  Strangely I could not open the com-port on my PC side successfully.  

Did I do anything wrong in the process?  

[AlanLevy]

The fourth parameter defines the address offset of a daisy chain configuration register for UART4 RXD (IOMUXC_UART4_IPP_UART_RXD_MUX_SELECT_INPUT). Daisy chains are used to configure input signals which can come from more than one device pin; they are not supported for output signals, hence the difference. For a bit more information about this see the i.MX53 Reference manual Rev 2, section 4.2.2. None of this is particularly well documented and quite a few of the pin configuration macros in Freescale's Linux kernel headers are incorrect (or at least they are in the version of the kernel that comes with Android).

[VincentChou1z]

Hi! Alan,

I think this is a very good suggestion.  I also want to know the meaning of the fourth parameters in the macro.  Why should we change the value to 0?  What does it mean?  Why don't we change the same parameter on RXD of UART4 as well?  Any document we should check for the meaning of the macro?  I think your suggestion will be very helpful!

VIncent

[AlanLevy]

The macros that define the values for MX53_PAD_CSI0_DAT12__UART4_TXD_MUX and MX53_PAD_CSI0_DAT13__UART4_RXD_MUX are incorrect. On our system we are using KEY_ROW0 and KEY_COL0 and we had to re-define those macros to get UART4 to work. A quick examination of the equivalent macros for CSI0_DATx suggests that the same changes are required but there may also be other things wrong:

- replace MUX_PAD_CTRL(NO_PAD_CTRL) with MUX_PAD_CTRL(MX53_UART_PAD_CTRL) in the macros MX53_PAD_CSI0_DAT12__UART4_TXD_MUX and MX53_PAD_CSI0_DAT13__UART4_RXD_MUX

- change the fourth parameter in the macro _MX53_PAD_CSI0_DAT12__UART4_TXD_MUX from 0x890 to 0.