AM3359 UART Rx FIFO Overrun Error (Custom Board)

Forwarding this to the SW team.

Hi Biser,

Thanks.

I have an update for the SW Team

We are using "pcm051_defconfig" and not  "omap2plus_defconfig" for the custom board.Sorry for providing wrong defconfig information in the issue posted by me previously.

Regards,

Rahul Gaur

Hi Georgi,

Sorry for the delayed response.

I have not yet tested with the newer kernel version. I am waiting for the newer kernel source from Phytec.I am not aware of the SDK version used by Phytec to develop BSP.

I have modified some part of omap-serial.c in our linux-3.2 kernel taking reference from omap-serial.c present in linux-3.11 kernel at http://lxr.free-electrons.com/source/drivers/tty/serial/omap-serial.c?v=3.11#L61.

The overrun issue is observed only when UART 1(19200 bps,8n1),UART2(115200 bps,8n1) both are communicating with our linux application running on the am3359 module.

The issue does not occur at all:

1. When UART2 is communicating with the application and UART1 is not connected/used.Kindly note that UART1 communication is continuous and exchanges packets with our application at every 100 milliseconds.

2. When UART2 baudrate is less than 115200 bps (checked at 9600,19200,38400 bps) and UART1 is also connected.This might be worth noting.

I have found the execution time of spin_lock_irqsave() used in the serial ISR to be 30 microseconds which seems to be too large.For 115200 baudrate, the whole ISR itself shall not take time more than 8.68 microseconds for 1 byte interrupt mode.

The code snippet which calculates the execution time is shown below.Also,please let us know if this shall give correct approximation of execution time.

static inline irqreturn_t serial_omap_irq(int irq, void *dev_id)
{
        struct uart_omap_port *up = dev_id;
        unsigned int iir, lsr;
        unsigned long flags;
        int retval;

        pm_runtime_get_sync(&up->pdev->dev);
        iir = serial_in(up, UART_IIR);
        if (iir & UART_IIR_NO_INT) {
                pm_runtime_mark_last_busy(&up->pdev->dev);
                pm_runtime_put_autosuspend(&up->pdev->dev);
                return IRQ_NONE;
        }

        struct timeval tstart, tend;
      

        /********The code below calculates the execution time taken by spin_lock_irqsave() for UART2*********/        
        retval =strcmp(up->name,"OMAP UART2");
        if(retval == 0){
          do_gettimeofday(&tstart);      
          spin_lock_irqsave(&up->port.lock, flags);
          do_gettimeofday(&tend);
          if( (tend.tv_usec - tstart.tv_usec) > 0)
             printk(KERN_ERR "spin_lock_irqsave(): start time =%lu microsec  end_time= %lu\n",tstart.tv_usec,tend.tv_usec);
        }
        else
          spin_lock_irqsave(&up->port.lock, flags);

Kindly let us know if you require further information. 

Regards,

Rahul

Hi Georgi,

Yes, we have already received the BSP PD14.1-rc1 images.We need to make some important changes to generate the same scenario.This might take some time.

But for time being, inorder to debug the exact problem with the existing omap-serial driver,I am planning to check the eact interrupt latency using oscilloscope.

I will share the results with you if required in near future.

Regards,

Rahul Gaur

Hi Georgi,

Greetings.

I would like to update that the latest PD14-rc1 linux source has not yet been released  by Phytec .Only BSP images have been released which is not useful for debugging the uart overrun issue faced at our end.

I would also like to know your valuable suggestions to debug and fix the issue.

Regards,

Rahul Gaur

Hi Georgi,

The phytec link shared by you does not lead to the linux source (linux-3.12) used to build PD14-rc1 images. Please confirm the same. We are also trying to get the source from Phytec.

Regards,

Rahul Gaur

Also you can refer to
19.3.8.1.3 UART Data Formatting in AM335x Sitara Processors TRM

www.ti.com/lit/ug/spruh73l/spruh73l.pdf

looks like the problem is in Rx FIFO .

BR,
Georgi