Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hello,
I'm using the UPP on the OMAP-L138F to receive video data that's been buffered by the Xilinx FPGA. The FPGA logic is based on the source provided in the Vision Developer Kit and is mostly intact except it has been modified to handle two 8-bit video streams that are split into Channel A and Channel B of the UPP. Just like in the VDK, the logic samples the video data using a pixel clock, uses the state of the line and frame sync signals to generate the start and enable signals, and these are buffered in a FIFO that transmits to the UPP. The UPP receive clock signal is constantly driven by a 50MHz clock derived via the clocking module from the 100MHz EMIF clock. I did not use the wait signal to halt the data flow because I read in a TI forum post that it's only used during emulation, hence not necessary for my application.

The logic appears to be working except the UPP appears to occasionally miss a line interrupt. I've verified this is the case by enabling the line interrupt in UPP configuration and checking the flag inside the UPP ISR. The DSP toggles a GPIO line when a line interrupt occurs and this is captured on a scope. I see instances when this line is not toggled (i.e. the line interrupt did not fire). Analyzing the logic traces also revealed the previous line interrupt did not occur at the correct time (it was late) and the timing of the enable signal for this 'late' line was slightly off, but not so much that it should have caused the interrupt to be late. I've determined that this is the case for every missing line interrupt. That is: the enable line has timing that is slightly different that the norm, the line interrupt for this line time period fires late, then the subsequent line interrupt is missed completely. I traced this enable signal timing 'abnormality' to the first FIFO used to hold samples of the video data, hsync, and lsync signals. The timing of the enable line is controlled by the PROG_EMPTY signal coming from this FIFO. I've posted a screen capture of the traces to illustrate.

As best I can tell, even though the timing of the enable signal is slightly different than the norm, it does not violate how the UPP expects the signals to be driven and the line finishes in time for the line interrupt to fire. I can speculate that the timing on the enable signal may have thrown off the byte count for the incoming line and the UPP ignored the start pulse and kept counting the incoming bytes until it reached its programmed bytes/line count, then threw the line interrupt flag. Can you think of any reason why the timing 'abnormality' on the PROG_EMPTY line from the FIFO would be caused. Any other thoughts on how I can further troubleshoot and fix this issue?

Thanks.