Interrupt Latency

The interrupt is accepted when (a) GIE is set, (b) the CPU finished the current instruction, and (c) the DMA just finished its memory access.

In your case, the interrupt is accepted at the next clock cycle after IFG is set. Thus the latency is always 6 cycles.

How did you determine the interrupt latency? What did you get?

Well that is what i thought also.  BUT i am getting "erratic" results when i try to operate the CPU from LPM0 mode.  It must be in my code...i'll keep looking.  Thanks for the help.

As to your question, I am using the MCU to generate a non-interlaced NTSC composite video signal.  In my implementation, each "line" is 63.5us long and each "frame" consists of 262 lines.  Each line starts with a negative pulse.  This pulse is used to synchronize the oscillators on the monitor.  My problem is i drop sync each time a frame changes.  I regain sync after about 10 lines but this is not right.  If i take the CPU out of LPM0 mode (and put it into an infinite loop) i can maintain sync for all but the first 2or3 lines.  If i dont use interrupts at all (and count cycles) i can maintain sync for all lines!...so i "see" what appears to be a random delay when waking from LPM0 mode.

Make sure your ISR finishes before the next interrupt!

I still see the problem when i leave the isr early. 

I definitely see a difference when i put the cpu to sleep vs putting it into an infinite loop.  But still not sure where problem lies.  Interestingly, when i display dashed vertical lines each dash shows the same issue.  See attached (this is turned sideways)....

Are you showing the video signal or the video?

Would be nice to see what happens when you draw longer vertical lines? Try f.e. 32 TV lines with dashes, then few lines (4 or 8?) blank and so on. And please rotate your picture(s) before uploading, don't let us do it for you.

Brett Nourrcier said:

My problem is i drop sync each time a frame changes.  I regain sync after about 10 lines but this is not right.  If i take the CPU out of LPM0 mode (and put it into an infinite loop) i can maintain sync for all but the first 2or3 lines.

The question is: why are you able to regain sync at all? Usually, either it works or it won't.  So what's the difference that makes you regain sync after 10 lines in one case but after 2-3 lines in the other.

If it were a static problem, I'd expect no sync in one case and perfect sync in the other. Or no sync in both.

Wakeup form LPM only takes one clock cycle. Plus ISR latency.

Maybe it's time for some math: How many nanoseconds off are you when sync is 'lost'? Knowing the horizontal speed of the monitor and the visual distortion, this should be no problem to figure out. Then compare this to the MSP clock and CPU speed. IIRC, on NTSC, one screen 'pixel' is roughly 100ns (~10MHz dot clock).

So what you see as 'random delay' is in the range of a clock cycle and may be simply caused by clock synchronization between the hardware trigger and CPU clock.

Sorry.  That is a photo of the monitor screen. Sideways. Yes i know. 

I think i found some of the problem.  Actually 2 of the problems.  The first was with the monitor - it did not like seeing image data on the 1st line.  If i skip the first couple lines the bend in the line disappears...but i couldnt see that at first because of the 2nd problem.

I am using the USCI_B0 in SPI mode to outupt (on P1.7) my image data.  I use P2.0 as the other output pin and, for this test, tie both through 2 resistors to get the composite video.  In my first iteration (what you see above), i did not use the USCI to transmit blank lines - i simply exited the ISR once i pulled P2.0 high.  Since I always left the last bit out of the USCI low, I thought this would be ok.  But, i could never get the bend out of the line using this method.  I eventually stumbled onto having the USCI transmit both image containing and blank lines.  I have to make the 1st couple lines blank but otherwise everything works.  Here are two example photos of the output:

Of course, this is a work around and doesn't really explain why i cant exit the ISR early - or why i have to transmit the blank lines.  The transmitter is started and stopped on each image line.  If the issue was the transmitter i'd think each image line would have a random starting point.  But they don't.  They seem to get "better" as i transmit more image lines.  

I'll keep pushing.  Thanks for all the feedback and help!

Brett 

Brett Nourrcier said:

I eventually stumbled onto having the USCI transmit both image containing and blank lines.

Congratulations! In my opinion you shall output every line - blank or not, exactly the same way. Unless of course, you are making some HUD application which needs to display few but predetermined TV lines so optimization can free some CPU cycles for other stuff.

Yes, the composite video signal needs at least three voltage levels. White-level, black-level, and sync-level. What resistor values did you use? And what voltage levels did you get? Using two pins, you can actually get four different levels. (Above 3 and a gray-level.)

Most CRT display need some black-level lines before and after the vertical-sync lines. And also each line need to be at black-level at the beginning and near the end. These blank-level portions should be adjustable for vertical/horizontal position/size of the visible portion of the picture.

Looks like you may be able to generate black-gray-white pictures or even moving pictures. Let me know if you want to try and need help.