High speed timer counter

The MSP430F51x1/51x2 have two TimerD units supporting up to 256MHz input clock and can capture external events based on an internal high frequency generator derived from a normal 16MHz system clock (*16). Theyx can also generate PWM with up to 16 bit resolution and a PWM frequency of up to 128MHz (well, with 1bit resolution then)

The two timers are 16 bit each, but can be cascaded for a 32 bit timer/counter

Hi again,

If we think that the processor runs on a 8 MHz oscillator and the timer D input has a 150 MHz external clock source. When we use capture mode and when a signal come and trigger the timer, will an interrupt occurs immediately or will it wait until the mikrocontroller's main clock pulse finished? Because if it waits, it could make me lose some clock pulse counting.

Well, an interrupt to the MSP is handled by the MSP PCU core,. And if it runs on 8MHz, it will take (best case) 7 cycles of 8Mhz to enter the ISR and start code execution here.

Whether the clock was 160MHz or 8MHz, you would lose counts if doing this in software. Luckily, teh MSp does the capturing of the count even in hardware. It just freezes the timer count at the moment of a capture event in the capture register, where it can be read until the next event occurs.
On 8 MHz, I think the maximum event frequency will be ~500kHz. But the moment of the event can be detected with 256MHz precision.

Perhaps you should be a bit more detailed about what you want to do.

While using Timer D module for 256 Mhz precision and speed , will I need to use an external clock source that runs on ~250Mhz to run Timer module? Or Can I handle it using internal clock source, runs on 25Mhz. 

TimerD has its internal high-resolution frequency generator. Either you use the x8 or x16 mode which multiplies the timer input clock with equidistant clock ticks, or use the free-running mode. Details are found in the TimerD section of SLAU208i.pdf or the separate TimerD addendum SLAU323.pdf

When cascading a couple of Timer D in high speed mode, when capturing the time of an external trigger, will you get the 32-bit time?  The User's Manual is not very clear on this.  

The race conditions are exactly the problem I'm inquiring about.  If there is no hardware support for the capture signal going to both timers then I don't see a good way of determining whether the the capture on the low side timer occurred before or after the overflow.  How does having two timerD instead of a timerD+timerA help in that case?  

If the external trigger is routed to both capture inputs, then there is a good chance that the captured value is correct.  But there is still a small race condition, since there might be a delay difference between them.  Even if that delay is a single HiRes clock cycle, there is a chance of error. 

One (not so good) way is to look at the upper bits on of the current timer values and compare them with the captured value.  If the lower timer has a capture close to zero on the negative side, then the upper timer capture value would be the current value minus 1.  If the lower capture timer is close to zero on the positive side, then use the current upper timer value.  Otherwise simply use the captured value of the upper timer.

The main problem is that the High Res timer frequency is 256MHz (max).  At that frequency, timerD overflows every 256us.  If the combined interrupts that may happen at the same time but are serviced before last more than 256us, then the method above won't work.

All of this is solved if the capture trigger signal is also shared between the timers (and synchronized to the HiRes clock) when the timers are cascaded.  But this is not mentioned in the manual, so that is why I asked.  I don't think this is the case, and wanted some confirmation.

There is no synchronization method for two timers that have different clock sources. The time window for such a race condition is quite low, but it is there.
A possible way would be to synchronize the trigger signal with the clock signal and add a minimum delay, so that the capture trigger will be delayed to some minimum time after the count.
One or two logic gates and a monoflop (or a few gates, acting as delay logic) will do. All you need is to delay the trigger if it happens exactly at (or immediately after) a counting pulse.

Update:  Upon closer examination, the timer D's can't really be cascaded.  All you can do is synchronize the clear signals and share the same clock.  This can be seen on "Figure 20-5. Synchronization Between Timer Instances" of the "MSP430x5xx and MSP430x6xx Family User's Guide".  So the whole discussion was pointless in my case, since the only way to extend the counter is seems to be by counting in software using the overflow interrupt, or perhaps by routing an output compare back as the external TDCLK.

Yes, cascading two timers is of course done by routing a compare register output as external clock signal to the next stage. There is no internal routing of this kind. (would be great, if it were)