• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 423 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAP3530 UART3 TX Timing Delays

David Eastburn
Prodigy 100 points

Other Parts Discussed in Thread: OMAP3530

We are experiencing large TX delays on UART3 on an OMAP3530.  UART2 is our console port and and does not exhibit the delays.  We've compared UART2 performance with UART3 by dumping a text file out each serial port separately from the console and measuring the timing with an oscope.  The data TX'd on UART2 is consistently around 140ms.  We have seen TX times on UART3 from 300ms to 1.5sec.  Both UARTs are configured for 115200,n,8,1.

Notes:  

1.  Linux Kernel Ver:  2.6.27.18

2.  All user space applications are terminated with the exception of 'cat' were using to dump the text file out the UARTs

3.  Power management is disabled

4.  Data text file is ~1.3KB

5.  Scope data on UART2 is the output of RS232.  No RS232 driver on UART3

 

[   79.021942] Serial: 8250/16550 driver4 ports, IRQ sharing enabled

[   79.043792] serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654

[   79.064270] serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654

[   79.064331] console [ttyS1] enabled

[   79.242095] serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654

dmesg log regarding serial port driver on kernel boot:

 

 

 

The plot below shows the timing for the TX data on UART2 (~140mS)

 

The plot below shows the timing for the TX data on UART2 (~355mS)

  • 0
    TI__Guru* 95721 points

    Are both UARTs configured the same.  You may want to do a simple register comparison to make sure similar results are expected.  Especially look at the FIFO configuration and the divisor values.

    Regards,

    James 

  • 0 in reply to JJD
    TI__Guru*** 125430 points

    David,

    Is this issue still open?  If so, please post your register settings for each UART as a starting point for debug.

    Also, what other peripherals are in use while this test occurs?  I was looking for what differences I could find between UART2 and UART3 that might account for the behavior you're seeing.  First I saw that UART3 has capability to support IRDA but I wouldn't expect that to cause any issues in the normal mode of operation.  The other thing I noticed is that UART2 is hooked up to the L4-Core interconnect while UART3 is hooked up to the L4-Per interconnect.  One possibility that comes to mind would be accesses to other peripherals on the same interconnect blocking access for UART3.  The "Interconnect" chapter of the TRM has more details.  There are charts for "L4-Per Target Agents" and "L4-Core Target Agents" that show exactly what other peripherals are connected to each of these interconnects.

    Another thought that comes to mind is to see how adjusting the FIFO thresholds affects the issue.

    Best regards,
    Brad

  • 0 in reply to Brad Griffis
    Prodigy 100 points

    Brad,

    We (by chance) figured out the auto idle feature of the UART was the culprit here.  By disabling the auto idle feature via the SYSC_REG (bits 4:3 = 0x1) register eliminates the delays.  Below is a before and after of the register setting for both UART2 & UART3.  The problem may lie with UART3 being on the L4-Per bus as you mentioned.  The only peripheral that could be taking priority on the bus is possibly a GPTIMER that Linux may be using.  We didn't further investigate this to determine if the issue resides solely with the UART peripheral or bus precedence with another peripheral.

    I've also attached the register comparison between UART2 & UART3.  Note, the list is not a exhaustive list of all register settings.

    David

     

     

    Register settings prior to change:

     

    UART2:  0x15

    UART3:  0x15

     

    Register setting after change:

    UART2:  0x15

    UART3:  0x0D

     

    5127.UART2_3_Cfg_Cmp.xls