Capture Mode

Hi Nghich chan,

It looks like this diagram comes from the 2xx user's guide www.ti.com/lit/pdf/slau144 and shows the state machine for the Timer_A module in Capture mode. There is a lot of information in the user's guide throughout the rest of the chapter on Timer_A that might help you understand this mode.

Background:

In capture mode, the Timer_A module stores the current timer count when a particular event occurs on a pin input to the timer - the capture event could be set to be the pin signal rising edge, falling edge, or both (captures on both edges). So the capture mode can be used to record time events for measuring time between edges, calculating the frequency of a signal, getting a timestamp when something occurred - things like that.

State Machine:

You should start reading this at the No Capture Taken state - this is where you'll start when the module is first initialized. Wherever the arrows list "Capture" on the chart, that means a capture event occurs to move between these states - the capture event is caused by the signal on the input pin rising or falling edge occurring (based on how you've set the module up for capture mode).

The Capture Taken state is when one capture has occurred - at that time the timer count is stored in the corresponding TAxCCRx register for your code to retrieve later. The "Capture Read" event arrow is when your code comes and reads out the TAxCCRx register value.

The main thing to take away from this chart is the case where a second capture event occurs before you have read out the TAxCCRx result from the previous capture. In that case, the earlier capture result in TAxCCRx is going to get overwritten, so the COV (overflow) bit will be set to notify you that you are missing one of the capture datapoints. You do not want this to happen as it would mess up your timing calculations that you are basing off of your capture data. So the main thing is to know what the signal coming in that you are triggering from will look like, and what kind of frequency your capture events could be triggered from that signal - then you need to make sure that your code will read the capture data out fast enough that you won't run into overflows like this. You also should add checking and  handling in your code to correctly handle if a capture overflow ever does occur.

I hope this helps give a clearer understanding.

Regards,

Katie