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.

OMAP L138 UPP underrun/overflow

We're trying to get UPP to work transmitting data from the ARM core to an FPGA.

We've followed the set up based on the sprugj5b datasheet, and can send 7Mb blocks over, with a data rate of around 120MB/s, however we are getting overflow/underrun errors showing in the UPIER register.

Analysis shows that the only way to fix this is to create an interrupt handler for UPIER (as per section 2.6.4 in the datasheet) and force a short delay in the EOL / EOW events via a tight loop, along the lines of:

if (interrupt_status.EOWQ) {

    UPIER.EOWQ = 1;

    for (volatile v=0; v<10000; ++v) ;

}

This seems rather brute force, and slows down the data rate significantly.  We're also forced to determine a suitable delay length by trial and error:

Do you know the ARM->UPP transfer rate can be run successfully at 120MB/s?  

Is there a better way to determine how long to delay in the interrupt handler, ie should we be waiting for another signal to clear, something like:

if (interrupt_status.EOWQ) {

    UPIER.EOWQ = 1;

    while (<some signal>) ;

}

?

  • The following TI wiki page gives a throughput of uPP.
    processors.wiki.ti.com/.../Introduction_to_uPP

    What uPP configuration are you using ?
  • That table is useful, thanks!  We're running 1 channel 16 bit.  We do see 120Mb/s, but with the overrun/underrun errors.

    Should be doing something in the interrupt handler for EOL/EOW to slow down the process enough to stop these errors?  Is there some signal we should be waiting for?

    As I said, currently we wait via a tight for loop, but there must be a better solution.

  • Further investigation has considerably narrowed down this problem.

    We believe that memory contention is causing the UPP to lose data, and we wonder if other people are seeing this?

    We have set up our UPP as two channel rx/tx 16bit, running at half clock frequency, with the recommended values as per the UPP User Guide 2.6.3.  We are repeatedly sending 7Mb blocks of data from the ARM to an FPGA via the UPP.  Our BCNT value is set to 8192.  Like this, we always eventually see errors in the data, by which I mean that as we send each 7Mb block, eventually one of them will be corrupted.  Sometimes, but not always, we also get an underrun/overflow error. 

    If we set the main OMAP system priority registers MSTPRI0 & 1 such that UPP has priority 0 and nothing else is less than 2, ie the UPP has a higher priority than anything else, the data corruption disappears, until we perform anything else on the OMAP ARM chip, such as merely sshing into it, when we immediately see data corruption.

    The corruption is always of the same form - we miss 512 bytes of data in the transfer.

    Has anyone else seen this?  Has anyone managed to transfer any large amount of data without errors?  We almost at the point of globally disabling all interrupts for the duration of the transfer, but this is not a great solution.