MSP430F5522 Gated Counter

Hi Scott,

So your signal oscillates in bursts (tens of cycles) >= 10MHz and then stops.  You want to know how much of the time between the start and the stop was spent with the signal high.  Is that right?

If so you might need one of the new MCUs with the Timer D module.  Without the Timer D module and its 200+ MHz timing, measuring pulse widths isn't going to be very accurate if your signal is >= 10MHz.

The idea would be to let the Timer capture each signal edge and keep a tally in the interrupt handler or perhaps use the DMA controller to keep a list of the capture values for later processing.

Jeff

Jeff,

 

Thanks for the answer (which did make me look up Timer_D). My application is a little different from what you wrote. An analogy would be how much time does an analog signal exceed a certain value. Passing the signal through a comparator, the output is either high or low. Knowing the period I'm measuring the signal over, I want to find out how long (time-wise) the varying analog signal exceeds the certain value. That's why a gated counter would work.

However, your idea of capturing the timer values with each transition (with DMA) may work, depending on how quickly I can process the information and get ready for the next analysis.

Regards,

Scott

Scott,

Interesting problem.  Thanks for the clarification.  I decided to read about Timer D, too.  It's not quite what I was expecting, but it will help improve resolution of both capture and compare situations.

If your signal is really 10MHz, even Timer D won't help you capture all of those edges (in spite of what I said in my first post).  They just come too quickly, even for the DMA controller.  The fastest configuration for captures I can think of would still capture frequencies only up to MCLK / 4, which is about 6MHz at best.  The captures would be high resolution thanks to Timer D, but unfortunately we just can't get enough captures to characterize higher frequencies.

It's a shame really.  A timer clock so much faster than MCLK (250MHz vs 25 MHz) really begs for a capture/compare FIFO.

I can think of a few solutions that require additional hardware (and not much!), but I can't think of anything that would let you solve this problem just with the MCU.  Unfortunately even the DMAEN idea has unrecoverable resolution problems.

Jeff

 

Jeff,

I'm an idiot and you kept hitting me over the head with it. The pulses are longer than 100 ns!  My stupid mistake was on the algebraic symbols. Really, the confusion was in time versus frequency.

Based on this conversation, here are a few ideas that I think will work:

- The original DMAE0 idea.

- There are only 1,000 possible clock pulses between the start and stop. Capture a counter with each edge of the gating signal with DMA into RAM and post-process.

- Use DMA to capture the gating signal at each clock pulse. Put the signal into PX.0 and make all the other bits 0, then sum the captured array as a post-process.

Regards,

Scott

Some creative ideas, I'd say.

Using the DMA to block transfer the PxIN register seems like maybe the best idea so far, as long as you don't mind cutting out CPU activity during the block.  Be sure to use block transfer and not burst block transfer. 

Will the resolution be high enough for you?  If MCLK is 25MHz, then your sample rate is 12.5MHz, ie, 80ns resolution.  When your pulse widths get near your worst case of 100ns, you won't be measuring their widths very precisely.  If luck is with you, then in your application resolution becomes less important as you get near this worst case.

The DMAE0 approach seems doomed to me because there's a resync ambiguity built in.  The DMA controller has to resync every time DMAE0 goes back high.  The first DMA transfer takes 4 cycles, subsequent transfers as long as DMAEN0 remains high are only 2 cycles each.  It almost sounds like an intractable conundrum.

If you use the timer capture idea, you could route the gating signal to 2 inputs of the same timer.  One could capture rising edges, and one could capture falling edges.  That might help to make sure you don't miss edges due to capture overflow.

Jeff

Jeff,

Thanks for the inputs. I've got a few things to try out here and I'll see what happens.

The resolution isn't really a problem. I'm more concerned with wider gate pulses than very short ones. I just need to make sure I capture all of them.

All this for want of a real clock gate/enable pin.

Regards,

Scott

Scott Rosenthal said:

I just need to make sure I capture all of them.

All this for want of a real clock gate/enable pin.

Well, even with a 'real' enable pin, your can only cvount as many poulses as your counter is wide. So the limit is 65536 pulses on a 16 bit counter, no matter whether you do it with the CCR units or with a gate. YOu can use an external latch which is gated by your gating signal and routes the pulses to the timer input as count pulses. THen only the pulses duriong 'open gate' appear there,. Still you are limited to 16 bit counting width (unless you use external hardware to do a /2 or /4 divide, extending the range but limiting the resolution), and you still need to trigger an interrupt on 'gate close' to know when you're done counting.

Using CCR0/CCRx and subtract them from each other is the easiest way to solve your problem as long as there are <65536 pulses per gating.