This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3517 using UART4 on camera pins

Other Parts Discussed in Thread: AM3517

Hi,

I am trying to make working the UART4 on AM3517. The pins multiplexed with Camera re used on my board (gpio_95, gpio_96, gpio_97, gpio_98). I am working with Linux mainline (3.3).

The serial is correctly initialized - however, I cannot see any activity on the TX line. I have checked with a JTAG debugger the values for pinmux and clocks (both ick and fck). The fck clock is not reported in TRM, but I read in this forum it is 23 of PRCM.CM_FCLKEN1_CORE. This is set.

Reading the pinmux, I get:

480021e4 : 0002010c 011a0002 010c0102 010c010c  ................
480021f4 : 010c010c 010c010c 0100010c 01000000  ................
48002204 : 01000100 00000000 00000000 01080108  ................
48002214 : 010c010c 01080104 01080108 01080108  ................
48002224 : 01040108 01080108 01000108 01180100  ................

Pinmux is set to Mode-2, that is uart instead of camer.

And reading the PRCM clock, bit 23 for both FCLKEN1 and ICKEN1 are set.

48004a00 : 00806001 00000000 00000004 00000000  .`..............
48004a10 : 7fbffedb 0000001f 00000004 00000000  ................
48004a20 : df7f9e1d 0000001f 00000009 00000000  ................
48004a30 : 43fffe58 00000000 00000004 00000000  X..C............
48004a40 : 0000030a 00000000 00000020 00000007  ........ .......
48004a50 : 00000000 00000000 00000000 00000000  ................

However, I do not see what I am sending - does anybody know any issue using these pins as UART instead of camera ? Does anybody have success with it ?

Is there any other important subsystems I should enable for UART4 ? 

Thanks,

Stefano Babic



  • Seem remember some posts about UART4 on the AM3517.

    http://e2e.ti.com/support/omap/f/849/t/150677.aspx
    http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/52397.aspx

    I think it had something to with register address errors in the TRM and it was tricky to get UART4 included in the kernel build.

  • It seems, but I had already found and read the two posts and I am sure that the issues mentioned are fixed. Even if I am not working with the same kernel (I work with mainlinekernel instead of an older TI's),  the problems explained are fixed by me or by a recent patch for linux-omap that add the two missing clocks for uart4 on am3517.

    The uart4 appears in the system, and I can try to send something simply using echo in a shell. However, nothing happens ;-(

    What I do real differently is that I am using pins that normally are for the camera - this let me think to a wrong pinmux setup, but the output of the JTAG debugger seems correct and sets the pins for uart4.

  • The mainline kernel looks to have cleaned up the mess of defines. It might still have the wrong base address for UART4. The post by Jeff Culverhouse would imply it should be 0x4806E000 and not 0x4809E000. Is the JTAG dump of the pinmux after Linux has totally booted?

    Perhaps you should test the HW. You could configure the TX line as a plain GPIO output and toggle it. Maybe you have a short. That's all I got.

  • Norman Wong said:

    The mainline kernel looks to have cleaned up the mess of defines. It might still have the wrong base address for UART4. The post by Jeff Culverhouse would imply it should be 0x4806E000 and not 0x4809E000. Is the JTAG dump of the pinmux after Linux has totally booted?

    Yes, it is.  The address is also correct:

    [    0.686248] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
    [    0.688354] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
    [    0.689910] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
    [    1.417755] omap_uart.3: ttyO3 at MMIO 0x4809e000 (irq = 84) is a OMAP UART3

    I will set the pins as gpio as in your proposal - maybe something is wrong on the board.

    Thanks,

    Stefano

  • My eyes must not be working. I still see 0x4809e000 for the fourth UART. You could try 0x4806E000 instead.