Other Parts Discussed in Thread: OMAP-L138
Hello,
I'm using the UPP on the OMAP-L138 to receive video data that's been buffered by an FPGA. The FPGA logic stores the video data and generates the start and enable signals to the UPP to control when it receives the video data, which is 8-bits. The UPP clock signal is constantly driven by a 50MHz clock. I did not use the wait signal to halt the data flow because I read in another forum post that it's only used during emulation.
This configuration works 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've included 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 it completes the line 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. But, my understanding of the UPP was the start pulse resets the line count for the DMA engine for each incoming line. Is this actually the case or does the engine wait for the byte count per line to be reached for each line (i.e. start pulses are ignored) before the line interrupt is fired? Any other thoughts on how I can further troubleshoot and fix this issue?
Thanks.
