This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

how to keep a running FIFO of ADC samples

Other Parts Discussed in Thread: MSP430F2618

Hello, I am a newbie poster but with perhaps a common problem to solve.

I am using MSP430F2618, and need continuous  ADC conversion (using ADC12 probably) @ 30KSPS (synchronous), for an event detector.

Upon an external HW interrupt, my code analyzes the last 1Ksamples taken, performs FFT and some other signal analysis (the interrupt is generated by an event, and the samples need to be analyzed to validate the conditions leading to the event).

Thus I need to use RAM as a "trailing FIFO" of samples.

The big question: How do I do this with lowest power? The vast majority of time the system is doing nothing but collecting ADC12 samples and stuffing them in RAM (FIFO), waiting for the interrupt.  I can use DMA modes as shown in http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/55857.aspx, but DMA needs MCLK on and so I am stuck with running all the time in active mode. Any better way? Or at least maybe I can minimize currents somehow better than DMA. By the way, during interrupt /analysis, the ADC can stop converting.

Respectfully wondering if anyone has ideas,

Martin

 

 

 

  • If you only have one channel, you can use the DMA to automatically move any sampling result to a memory location of programmable size (ring buffer, filled from 0 to max and then again from 0 to max).
    It should be large enough for 1k samples plus the number of samples that might happen during the analyze run (unless you temporarily stop the ADC if you know the next event won't be before another 1k samples are done after reactivating it)

    The current point of buffer-filling can be determined form the DMA controller count register, so you know which was the last value written to the buffer, and you can use the 1000 values before (with wrap-around).

  • Thanks. It sounds like DMA is required (and thus I need MCLK running all the time with no sleep mode, and so I will have to burn the current). Perhaps I can carefully turn everything else off. Best regards and thanks for the reply.

  • Hi Martin,

    You can still use sleep mode, and MCLK doesn't have to run all the time.  The DMA controller automatically activates MCLK temporarily (while leaving the CPU off) just long enough to perform the transfer.  It's transparent to the CPU and the sleep mode.  If the DMA transfers one conversion every 33us, that gives you some pretty good power savings in between transfers.

    You can also maximize your sleep time by using the "repeat sequence of channels" mode in the ADC12.  After 16 channels (with the MCLK and the CPU off), the DMA can jump in, transfer all 16 samples in block mode, and generate an interrupt.  You would need a very short DMA ISR to advance the DMAnDA pointer.  If you can tolerate inserting data into the FIFO in chunks of 16 conversions, this approach will save you even more power.

    Out of curiosity, what is triggering your synchronous ADC conversions @ 30kHz?

    Jeff

  • Hi Jeff,

    That's useful info thanks- sounds like just what I need. For the 30kSPS ADC conversions I could do one of two things:  (1) was hoping to use an internal resource- triggered from SMCLK-based clock which at least is on in LPM1. The samples must be timed with low jitter, so a crystal-PLL based clock is needed. But this still takes some current and it must be always on (I'm really tight on power). Maybe there's a better way? or (2) I could use an external clock (there seem to be a few low power ones out there) and trigger the ADC12 conversion - and subsequent DMA transfer- with a HW interrupt at each clock cycle .

    Any thoughts on this subject are very welcome. Seems a common point so I apologize for being a newbie..  Martin

     

  • Jeff Tenney said:
    You can still use sleep mode, and MCLK doesn't have to run all the time. 

    Yes, but the MCLK clock source mus tbe running or you'll have the wekaup tiem applied to the DMA too. So LPM0 is the maximum you can do (unless you construct your own LPM - LPMs are just predefined bit combinations anyway, to name a specific CPU state)

  • Jeff Tenney said:
    You can still use sleep mode, and MCLK doesn't have to run all the time. 

    Yes, but the MCLK clock source mus tbe running or you'll have the wekaup tiem applied to the DMA too. So LPM0 is the maximum you can do (unless you construct your own LPM - LPMs are just predefined bit combinations anyway, to name a specific CPU state)

  • It looks like if I use DCO (for MCLK) for DMA, it starts up in 6usec.

    It seems like one could start up DCO while doing an ADC conversion.

    Then the DCO is ready to go for the DMA after ADC conversion.

    (note the ADC conversion requires 2.5usec reference+buffer startup, plus 5usec or so for the conversion)

    Sounds like some careful coding required...

  • Martin Tomasz said:
    It seems like one could start up DCO while doing an ADC conversion.

    No need.  Just let the DMA controller start up the DCO (and MCLK) for you automatically once the ADC conversion is complete.  The DMA will finish with plenty of time to spare.

    Plus if you can manage to collect 16 ADC samples before starting the DMA, you'll have only one 6us DCO startup for the whole batch.  The DMA will still finish with plenty of time to spare.

    For triggering the conversions in a low-power way, could your application tolerate a 16384Hz sample rate instead of 30000Hz?  If so, you could have XT1 drive a 32kHz crystal (only 1 or 2uA), and a timer using that clock could trigger the conversions.  Very low power, and very low jitter.  But it's not 30kHz.  The fastest timer OUT frequency is the clock source divided by 2.

    Jeff

  • Unfortunately I think there's a fundamental problem here (maybe- comments welcome).

    Good idea to use 32kHz oscillator. I can live with 16384 Hz and sampling rate. The idea seems to move me closer to an ADC sampler at a few uA.

    The ADC12 needs a fast conversion clock that runs at least 13x the sample rate- I suppose that could be ADC12OSC which could turn on when a conversion is triggered by the 16384Hz clock.

    But I am concerned about whether these conversions will be truly synchronous.

    In other words, there seems uncertainty in the exact sampling moments.  The rising edge from the 16384Hz clock triggers a number of steps to wake the ADC and perpare it before the ADC12 sample is actually taken in step 4: (1) ADC12ON=1, (2) ENC=1, (3) SAMPCON=1 (now tracking the signal, wait for 5usec or so), (4) SAMPCON=0 (lock analog sample, start conversion), (5) apply a fast clock (e.g. ADC12OSC) to run the conversion.

     Since the (faster) clock that I rely on to time (1)- (5) must itself turn on when the 16384Hz clock triggers it, and there is uncertainty as to how long it takes to start ticking (maybe 5usec), it seems I can't have a reliably synchronous ADC sampling scheme with precise sampling periods (where the ADC sleeps between the 16384Hz timing triggers).

    Am I accurate in my concern or am I missing something?

    Martin

     

  • Hi Martin,

    The fundamental problem you describe is real.  However, its impact is probably not as large as you fear.

    1. With your configuration, ADC12ON=1 and ENC=1 are permanently true.  (No timing issue there.)
    2. The timer will drive SAMPCON=1 directly.  (No timing issue there.)
    3. The ADC12 sample-and-hold timer will drive SAMPCON=0.  Yes, there is a timing issue here.
    4. Then the conversion occurs.  No timing issue here as long as it's fast.

    So, only #3 has a legitimate timing issue because you want the width of the positive pulse on SAMPCON to be perfectly consistent, but it may not be. 

    MODOSC starts up when the timer drives SAMPCON=1.  There is no 5us delay/mask mechanism, so the sample-and-hold timer starts counting ticks immediately. After the appropriate number of MODOSC ticks, the timer drives SAMPCON=0.  This is the pulse you want to be perfectly consistent.

    Assuming your sampling time is short (low source impedance), you just need the MODOSC startup profile to be consistent.  (The final, settled oscillation rate of MODOSC is irrelevant because you won't ever let it settle.)  Well, you know the startup profiles won't be perfect, but they will be pretty good.  And likely, good enough.  Temperature and supply voltage impact the startup profile the most.  In your case, these are likely to be consistent right?  In fact, a lot of characteristics in the system you describe are consistent.  Unless you are trying to distinguish something very very subtle, your signal analysis (FFT?) will be just fine.

    And the shorter the sampling period, the better.  Shorter sampling periods would tend to drown out any inconsitencies in the MODOSC startup profile.  (So a nice low source impedence would be best.)

    Jeff

  • Martin,

    Also you should experiment with letting the timer (Timer A or B) control the sampling.  On the rising edge, the sampling cap would switch in.  On the falling edge, the cap would switch out and MODOSC would then handle the actual conversion.  It's just another ADC12 configuration option.

    There are no timing issues at all with this approach, but I don't know if there are power consumption issues.  When the sampling is happening, the ADC12 may foolishly start MODOSC.  It would run for half the 16384Hz cycle, which is a long time.  I don't know if the ADC12 has that shortcoming or not.

    Jeff

    PS - Be sure to configure the ADC12 for MODOSC/2 as the conversion clock.  Not only are there published errata regarding REF buffer strength, but also MODOSC can sometimes start with some overshoot.

  • thanks Jeff.

    two questions:

    (1) with ADC12ON=1, doesn't this mean the ADC12 draws current always (though I read somewhere that it's around 100uA when not actively converting, but that's still high for me !)?   I'd rather instead shut ADC12 off right after the conversion. Maybe that's not possible or easy.

    (2) if I were to leave ADC12ON=1, why not have the 16824Hz timer drive SAMPCON=0 directly? ; that is, SAMPCON=1 most of the time, tracking the signal; then the 16824Hz timer drive it low (synchronous sampling), then a short internal timer drives it high again?

  • Martin Tomasz said:
      I'd rather instead shut ADC12 off right after the conversion. Maybe that's not possible or easy.

    This would require software, and also software to switch it on again befor eth enext conversion. The CPU is likely consuming more than a permanently on ADC then.

    And yes, you can directly drive SAMPCON by the timer. To do so, trigger must be CCR1 (set to 1) set to set/reset, and the timer runs in up mode with CCR0=1 too. So samplign starts every second tiemr tick, and sampling time is 50% of the  conversion interval.

  • Hi Martin,

    This response is a bit late -- I had a little vacation time.

    Martin Tomasz said:
    (1) with ADC12ON=1, doesn't this mean the ADC12 draws current always (though I read somewhere that it's around 100uA when not actively converting, but that's still high for me !)?

    As JMG said, this would take software that is prohibitively power consumptive (probably).  Assuming you decide to leave the ADC12 "on" permanently, would you post back with the amount of current you attribute to it?  I'd be surprised if it really was 100uA, but I've been wrong before.  The precision voltage reference may use that much energy, but I don't think you're using it.

    Martin Tomasz said:
    (2) if I were to leave ADC12ON=1, why not have the 16384Hz timer drive SAMPCON=0 directly? ; that is, SAMPCON=1 most of the time, tracking the signal; then the 16384Hz timer drive it low (synchronous sampling), then a short internal timer drives it high again?

    Yes, as JMG and I mentioned, you can have the timer directly control SAMPCON.  That's probably the way for you to go.  Hopefully the ADC12 won't foolishly start MODOSC during the sampling half of the cycle.

    Jeff

  • thanks for the responses, JMG and Jeff. will consider this carefully. Martin

**Attention** This is a public forum