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.