ref this artical:
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/114045.aspx
It said that upp will never emit "WAIT" signal in transfer.
so, if upp is working, we start a EDMA transfer, the Upp transfer will be borken, right?
Is there an document talking about such conflicted peripherals?
The uPP peripheral has its own internal DMA that is separate from EDMA. For this reason, using EDMA and uPP simultaneously should not be a problem. TI has done testing to ensure that these activities do not interfere with each other.
Please click the Verify Answer button on this post if it answers your question.
But on my board, I do observed that EDMA affectting UPP.
Maybe UPP peripheral 's speed is too high, FIFO is overflow.
Are you operating the uPP peripheral at maximum speed (i.e. 75 MHz)? If so, it is possible to encounter contention with other high-speed activity (such as EDMA transfers) on the internal system bus. If possible, I recommend slowing the uPP clock speed to see if that alleviates the issue.
Sorry for hijacking this post, but I am having this very same issue. UPP working as INPUT channel on an OMAP L138 (300MHz), UPP clock driven by the peripheral (FPGA) at 37.5MHz. As soon as I perform an EDMA3 transfer (from DDR into IRAM), UPP fails (i.e., I get an SIO_reclaim timeout error) even though the peripheral is still sending data.
EDMA3 transfer routine is the edma3_poll_mode() from the examples. Tried edma3_int_mode() with the same results.
Lowering the clock even more is not an option in this case.
Ideas?
Perhaps try raising the UPP's priority in the MSTPRI registers.
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------