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.

Silicon bug in OMAP-L138 UPP not in errata - UPPA_EN held high too long during DMA Tx

Other Parts Discussed in Thread: OMAP-L138

In our system, the OMAP-L138 DSP communicates with an FPGA over the UPP ports.  UPPA is configured for 8-bit Tx, using DMA transfers for best performance (with buffers in L1 RAM to avoid the need for cache invalidation).  We are sending 22 byte packets at regular intervals.  Wait is disabled, and UPPA_WAIT is always held low by the FPGA as well.

What we actually see in the UPPA Tx is that UPPA_EN is actually held high for 38 UPPA clock ticks, instead of the expected 22 ticks (to send 22 bytes).  On the FPGA end, this looks like an invalid packet.

We have thoroughly checked that the DMA is only set up to send 22 bytes.

Data lines are always zero during the extra 16 ticks.  By making the Tx buffer larger and filling the extra bytes at the end with 0xDEADBEEF, we have confirmed that UPP is not DMA-reading more data from the Tx buffer than it should be.  Only the first 22 bytes from the Tx buffer are ever sent on UPP; after that, all "extra" UPP writes have data lines set to zero.

We have checked the errata, and this is not covered anywhere.  So it looks like we've found a new silicon bug.  I believe our devices are on v2.1 silicon.

The workaround is fairly simple: only reject the packet if it less than 22 bytes long, and if it is more than 22 bytes long then discard the extra bytes.  On an FPGA it's fairly easy to be clever about this.  I can see this being a problem if someone tries using UPP to interface to another micro though, because receiving this with DMA would give buffer overruns.

  • Hi,
    We didn't see this odd behavior in our devices and lot of customers are using with out any problem (DSP to FPGA).
    What about the behavior when you increase/decrease the packet ?
    How about uPP TX clock ?
  • Hi Titus.  Sorry I didn't get back with a reply more quickly.  This dropped down my list of priorities, and I'm just doing some housekeeping now.

    It's not a big problem.  Like I said, it's easy for the FPGA to count clocks and ignore the "extra" Tx from UPPA_EN being held too long.  It's just an undocumented feature that we have to be aware of, is all.

    I haven't tried changing the packet size.  Decreasing it would break our comms, because there is important data in the last byte of the packet.  Since the FPGA already ignores extra bytes though, it would be relatively easy to increase the packet size on the DSP side, with no effect on the FPGA running.

    The UPPA clock is running correctly at 57MHz (clock-divided from 456MHz).

    If it helps, our configuration for UPPA is:-

    • In SYSCFG, UPP Tx clock source set to ASYNC3 (i.e. not externally clocked from UPP_2xTXCLK)
    • Dual-channel mode, DUPLEX1 (A transmits, B receives)
    • Single data rate, SDR interleave mode disabled (i.e. 2 independent channels)
    • Ignore WAIT
    • WAIT/START/ENABLE polarity all normal
    • Clock not inverted
    • Clock divide set to 1 (i.e. divide-by-2)
    • 8-bit transfers
    • UPP DMA channel I set to transfer a single 22-byte line

  • Reviving this old thread...

    I'm working on a new iteration of our product, using the same OMAP-L138 device with a new FPGA.  UPP transfers are still used, with the exact same code.  The new architecture sends 24-byte packets from DSP to FPGA over UPP.  The rest of the configuration is unchanged.

    We are still seeing the same issue, where UPPA_EN is held high.  So I can confirm that it does happen for different packet sizes.

  • In case it matters, we're building with Code Composer Studio v5.5.0.00077 under Linux. (I know it's a bit old, but we don't yet have a compelling business case to upgrade to CCS v6.) I doubt this is an issue though, because the bug seems to relate to the UPP peripheral itself. We aren't using TI libraries to drive UPP.