CCS/TM4C123GH6PZ: TM4C Hardware sample Averaging

Hello,

i tried to add the API call but it still doesn't work.

Once again my problem:

I use a sampling rate of 200Hz and i sample 4 channels -> so i get new samples every 5ms.

As trigger source i use a timer.

Now when i'm turning on the HardwareAveraging e.g. with 8 -> i expect to get samples every 5ms*8 = 40ms.

The Problem is i still get samples every 5ms (the adc interrupt still occurs every 5ms) ...?

So it seems to me that something with the HardwareAveraging is going wrong and doesn't work....

Maybe you can help me with the problem?

thanks a lot

chris

Greetings,

May it be noted - that among  the  'ADC functions'  (which Vendor's Ralph graciously provided/presented) appeared 'several'  ...  NOT appropriate for the TM4C123 family of MCUs!     (all those functions originated from the thread's creator (o.p.))     It is believed (ok - hoped) that (certain) of those 'illegal' function calls - may explain - or lead to - 'Resolution of poster's issue.'

This discovered by one of our firm's, young 'summer interns' - as she gains capability - w/each passing day.    (and great - focused effort)      Follows - one quick example (said to 'have been missed' by o.p.)

ADCClockConfigSet(ADC1_BASE, ADC_CLOCK_SRC_PLL | ADC_CLOCK_RATE_FULL, 30); // 16MHz     Note - all poster references have been to  'ADC0_BASE!'

Alas - the Driver Library 'takes issue!'   (twice)

4.2.2.3 ADCClockConfigSet
Sets the clock configuration for the ADC.
Parameters:
ui32Base is the base address of the ADC to configure, which must always be 'ADC0_BASE.'

Note:  For TM4C123x devices, if the PLL is enabled, the PLL/25 is used as the ADC clock   (thus the parameter '30' - appears incorrect!    Fine for '129 (480MHz) - NOT for '123! (400MHz) thus '25' proves proper)

Staff / I have surveyed the code which Vendor's Ralph - earlier provided - and have 'uncovered' the following:

• the function, ' MAP_ADCHardwareOversampleConfigure(ADC0_BASE, 64);'  appears to both Jennifer & myself - as (most) suspect.     That as: a) it is the function - substantially charged - w/managing the Hardware Oversampling;  b) that  function 'intends' to place the value '0x6' - w/in the 3 lowest bits - resident w/in Register  'ADCSAC.'      Yet we've seen/noted - 'deviations from that behavior!'    (0x6 causing an over-sample factor of 64 was expected -  but we (often) noted 0x0 - as  'ADCSAC's' content!    (which defeats/negates (any) 'over-sampling!)
• thus might it  prove safer - to reject the 'MAP' prefix - (instead) employing  the 'Flash-based Function ' ADCHardwareOversampleConfigure(ADC0_BASE, 64);'   Such eliminates the "MAP" function (actually the MCU's ROM function)  - as the source of error.
• beyond that - might the entry of  '0x6' - rather than '64' as the final parameter w/in ADCHardwareOversampleConfigure() - do the trick?    Our 'free' '123 LPads have - just now - 'Left the Building.'

While 'out of favor here' (and justifiably so) DRM coding may - in this limited case - arrive to 'Save the Day!'

• HWREG(ui32Base + ADC_O_SAC)  |= 0x06;   //  the intent here - is to force '0x06' - w/in the lowest 3 bits of Register ADCSAC
• In addition - the (earlier) suggested (addition) of function 'ADCClockConfigSet()' may be avoided - as Register ADCCC 'defaults' to 0x0 - insuring PLL/25  (i.e. 16MHz ADC Clk)   Q.E.D.

User may wish to 'effect these changes' - and report - we are 'too jammed' for now - to devote (more) time/energy - and believe this analysis to be both broad & deep - and to have succeeded!

Hi Chris,

 While you are getting great support from Ralph and cb1, I'd like offer my perspective on the hardware sample averaging. The average circuit will work such that it will take sample of a given channel x number of times (i.e. 2, 4, 8, 16, 32, or 64) consecutively before storing the average data to the FIFO. Let's suppose you are running at 1Msps. This means for each channel it takes a theoretical 1us to convert. If you configure the hardware sample average to 64, it will take 64uS to complete and store the average to the FIFO before moving to the next channel. It is not to take the average of a channel conversion every x number of 'triggers'. There are two issues with averaging every x number of triggers. This means there needs to another hardware buffer to store the intermediate value before the last trigger comes before writing the final average data to the FIFO. The second issue is that if the triggers are far apart then each conversion may not be so relevant to each other anymore. In your use case, the trigger comes every 5ms. What if the trigger is configured to come every few hours or days. Perhaps there is some application use case for that, but this is not how the ADC hardware averaging works in TM4C device.

  Please see the below diagram shown in the datasheet where A, B C and D are 4 different sample points of the same channel.

Ralph Jacobi said:

Can I inquire why your staffer and you feel that the setting of 64 would not apply a setting of 0x06 to the ADC_O_SAC register?

Surely - as I wrote - upon several occasions - after calling that function - our review of  'ADCSAC'  revealed 0x0.    This was done on two LPads - part of a prototype system for a client - scheduled for shipment tomorrow.    Client called - asked that this shipment 'Release Early' - thus it will not be until c.o.b. (close of business) tonight - that we can unbox new LPads.   We have many - in our warehouse.   (several blocks away - in a 'climate controlled' - yet far lower rent district.)

As you had the luxury of a less hassled test - we've not reason to 'doubt your findings' - and the finger in 'that portion of the 'straining dike' - may be removed.    I do believe we released that finding as 'possible' - and not as an 'absolute.'     And again - any discovery during troubleshooting - especially that which has dragged on - as this one has - IS SURELY to be PRESENTED.    (Early Judgment - so often - proves incorrect.) 

Jennifer and I have not had (yet more) time to read/review the latest postings here - (yours & one from Charles) - we'll 'try' to do that once our 'back-room' empties...  (staff/cast flees...)

Thank you - yet the 'RePositioning' of that shaded '4' - remains STILL beyond staff (uber smart) and myself (dull normal - on a good day.)
Staff 'guessed' that perhaps - an interrupt was generated upon the 7th conversion - yet no such detail (even now) has arrived.

Do you not see that clear disparity - w/in the diagram?     (that shift of 4 - from position #4 (expected) to position #3 (unexpected)     It clearly IS ... Krazy-Making ... yet  you made special effort to find - then present it.      Why has the '4' - shown w/in the right-side (packet of 4) placed w/in position 3?      What is the intent?      No one here 'gets that' - at all!

Might you be good/kind enough to somewhat detail?

As to the code you've just presented - that's clear - yet the earlier diagram - as we've really tried to detail - evades ALL of our group understanding.    (making us (more) Krazed!)      HELP!    Mercî...

Hi cb1,

 Hopefully, this will be a bit clear.

That (your vastly clarifying - added text) IS the missing link!      Thank you Charles - minus your clarification/amplification - we were lost.    (or staff - smarter than me - 'pretended' to be - @ my 'feeb level.')

May I suggest an improvement?     That diagram - which 'models' a '4-entry FIFO' (you've noted that) - also is representing a '4X Hardware Over-sample' (that's not noted - but is my impression) - is that  correct?     Thus - we've created 'possible confusion'  - via the TWO (different - and unrelated) occurrences of '4' - have we not?

How would your NOW (vastly improved) diagram - be  changed - if we kept the same '4-entry FIFO' - but  changed the "hardware over-sampling' - to '8X?'    Might the diagram then reveal (only) the entry into one of those 2 - '4-entry FIFOs' - and 'only after the 8th ADC capture' had arrived - and been processed?

It is hoped that I explained that w/sufficient clarity - and that you can - once more - 'ease our (unknowing) discomfort.

That said - our poster reported - that even w/configuring for a 64X Over-Sample - he received ADC interrupts - at the FAR HIGHER, 'NON OVER-SAMPLED RATE!     And that's 'STILL' of concern - is it not?

Staff just noted - your diagram shows (just one) interrupt - should not TWO have occurred?

Again - thanks for your time/effort/graciousness - in 'educating the uneducatable.'

Hi cb1,

cb1_mobile said:

How would your NOW (vastly improved) diagram - be  changed - if we kept the same '4-entry FIFO' - but  changed the "hardware over-sampling' - to '8X?'    Might the diagram then reveal (only) the entry into one of those 2 - '4-entry FIFOs' - and 'only after the 8th ADC capture' had arrived - and been processed?

  How about below diagram?

cb1_mobile said:

Staff just noted - your diagram shows (just one) interrupt - should not TWO have occurred?

No, it will only generate one interrupt. Let's use my code again to represent the diagram. The sequencer 0 has only configured two steps (step 0 and step 1). Both  steps will sample CH0. You can have 8x oversample or 64x oversample and that does not matter. Look at the second line where the ADC_CTL_IE and ADC_CTL_END are applied to the step 1. After step 1 is converted an interrupt is generated. Not that every 'step' completion will generate an interrupt. It is every 'sequencer' completion will generate the interrupt.  

ADCSequenceStepConfigure(ADC0_BASE, 0, 0, ADC_CTL_CH0 );
ADCSequenceStepConfigure(ADC0_BASE, 0, 1, ADC_CTL_CH0 | ADC_CTL_IE | ADC_CTL_END);

Ralph Jacobi said:

just because you enable Hardware Oversampling doesn't mean the timer is going to know that it has to interrupt less often. Try using ADC_TRIGGER_TIMER and have the timer set to your expected sample rate and not 5ms

I read this the first time - w/staff - we had 'mixed feelings.'     I've (some) experience - they've MAJOR SMARTS - together (on a good day) we may be 'dangerous.'    (one hopes)

Here is an attempt to present this 'ADC HardWare Over-Sample' issue - in a more systematic (understandable framework) building upon the efforts of (both) Ralph and Charles (and my gifted staff):

• Now our poster expects to accumulate 64 ADC Samples - and only then - when that data has been (processed/averaged) - receive an ADC Interrupt.    (so that he may (only) then - take action!)
• He has elected an ADC Sample Rate of 200Hz (5mS period) - thus - to achieve his 'GOAL' - does he not need to 'Achieve ALL 64 ADC Samples' - at minimum - 64 times faster - than he's now doing?
• Via 'back of a napkin (advanced) math' such yields 12,800Hz - for a 'new' Timer Triggered ADC Conversion Rate.    (Surely there will be time lost in 'overhead/processing' so it likely proves best to (somewhat) raise that frequency.)

We've not an LPad available at this moment - to code & observe (i.e. Test/Verify) - yet this seems a reasonable method - and the first one w/Full and Usable Detail - to enable Re-Launch & Test.

Again - thanks to Vendor Agents (and friends) Ralph & Charles - and my firm's inspiring young staff - for teaching this 'middle aged dog'  .. another New Trick.     ((maybe) - we shall 'Wait & See!)

Charles - Again great thanks. We are checking - we read something this morning - which may prove most useful - Please Standby.
(our motion - at least mine - noted as, 'Faster than a herd of Turtles' - Get outta our Speed Lane Charles - a little heavier on the HIGH BEAM ... BOYZ!)

Here is just one more point - in support of my firm's summary - advocating for a 64X FASTER (Minimum) ADC SAMPLING RATE - if and when - users seek to achieve such ADC Hardware OverSampling!

Poster wrote:  'looks like that the   HardwareAveraging only works if i use the ADC-Trigger: "TRIGGER_ALYWAYS" with factor 64......

Now - that Trigger Rate - is far too fast - and (likely) 'unjustified' - yet surely complies w/the 'calculated value (or beyond) which my firm supplied.     And provides positive confirmation - that hardware oversampling - ONLY Succeeds - when the  ' ADC Sample Rate  - at minimum - equals or exceeds - the desired sample rate Multiplied by the OverSample Rate!'   (and likely - w/ some extra (safety time) added.)

Now - (somewhat) in opposition to Charles' report - several staff and I recall reading - that HW OverSampling - REDUCES the INTERRUPT RATE - by the OVERSampling FACTOR.   (and it is not believed that Charles' conclusion (precisely) suggests that!)

We wish to (again) present Charles' earlier conclusion:   "Look at the second line where the ADC_CTL_IE and ADC_CTL_END are applied to the step 1.  After step 1 is converted an interrupt is generated.    Not that every 'step' completion will generate an interrupt.     It is  every 'sequencer' completion will generate the interrupt."    And - Staff / I believe - this writing deserves challenge!

ADCSequenceStepConfigure(ADC0_BASE, 0, 0, ADC_CTL_CH0 );
ADCSequenceStepConfigure(ADC0_BASE, 0, 1, ADC_CTL_CH0 | ADC_CTL_IE | ADC_CTL_END);

Review of his (earlier diagram - reproduced here - for clarity)  - brings challenge to that  'interrupt generation' claim!   (note that I've added key defining detail)

cb1_mobile said:

We wish to (again) present Charles' earlier coclusion:   "Look at the second line where the ADC_CTL_IE and ADC_CTL_END are applied to the step 1.  After step 1 is converted an interrupt is generated.    Not that every 'step' completion will generate an interrupt.     It is  every 'sequencer' completion will generate the interrupt."    And - Staff / I believe - this writing deserves challenge!

My statement on the 1 interrupt was in reference to the two lines of code I presented in representation of the diagram. It is legal to have multiple samples within a sequence generate interrupts. For example, if you change the code as below. However, why would you do that in the application. That is defeating the purpose of the using FIFO. 

ADCSequenceStepConfigure(ADC0_BASE, 0, 0, ADC_CTL_CH0 | ADC_CTL_IE);
ADCSequenceStepConfigure(ADC0_BASE, 0, 1, ADC_CTL_CH0 | ADC_CTL_IE | ADC_CTL_END);

Hi Ralph,

Good to note that you - and the bulk of our staff - still 'pounding.'

I've just added to my post (just above yours.) I'm rather convinced now - that the logic - and language - presented by my firm (team effort)  - exceeds - both in detail - and clarity (and surely COLOR) that (even) past presented.   Again - great inputs from both you & Charles - yet my group has, 'Sweat the Details - and produced a reasonably exact - systematic guideline.    (SO liked - by our major (especially) 'giant'  ...  clients)

Staff has earned 'Free Dinner' - at a decent joint - should my 'card' not 'carry the freight' - high (very high) stack of 'unwashed dishes' awaits us!     Which - all too often - echo's the condition of ... 'hacienda cb1!'    (Why wash - when you can BUY NEW?)

Charles - kindly read my 'Long & Colorful Post' addressing your great assistance - with (just) ONE - minor tweak.

My post - earlier today (5:14 / 17:14) with (very) high detail - hard (data sheet) facts - and we believe - highly logical findings & conclusion.

Hi cb1,

  No, the below cannot be true. Image you want to use SS3 which can only hold ONE step. If you want that only channel in SS3 to take the average of 64 samples how will you do that with your below code. 

Hi Ralph,

yes this is true but something still doesn't work. Once again my problem :-)

some facts:

-> i have to sample 4 channels

-> therefore i use sequencer 1 (fifo depth -> 4)

 ADCSequenceStepConfigure(ADC0_BASE, 1, 0, ADC_CTL_CH0);
  ADCSequenceStepConfigure(ADC0_BASE, 1, 1, ADC_CTL_CH1);
  ADCSequenceStepConfigure(ADC0_BASE, 1, 2, ADC_CTL_CH2);
  ADCSequenceStepConfigure(ADC0_BASE, 1, 3, ADC_CTL_CH3 | ADC_CTL_IE |ADC_CTL_END);

-> i use a timer for triggering the adc conversion (ADC_TRIGGER_TIMER) with a sample rate of 200Hz (5ms)

ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_TIMER, 0);

  SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER1);
  TimerConfigure(TIMER1_BASE, TIMER_CFG_PERIODIC);
  TimerControlTrigger(TIMER1_BASE, TIMER_A, true);
  TimerLoadSet(TIMER1_BASE, TIMER_A, 400000);  //cycle time 5ms or 200Hz
  TimerEnable(TIMER1_BASE, TIMER_A);

-> i use Hardware Averaging with a factor of e.g. 8

ADCHardwareOversampleConfigure(ADC0_BASE, 8);

Now i thought things would work like that.....

- every 5ms 8 samples per channel are collected averaged and saved in the sequencer FIFO

- So i will get an sequencer 1 Interrupt every 5ms*8*4 = 160ms.

-> The Problem is actually that my interrupt handler is still called every 5ms -> So  my assumption is that the Hardware Averaging doesn't work correctly..?!?!

Thanks a lot

chris

Hi Chris,

 Some questions. You are changing to use sequencer 1 now. Before you were using sequencer 0. If you are using sequencer 1, I hope you have enabled interrupt for sequencer 1 with ADCIntEnable(ADC0_BASE, 1).  Next question is you are saying you are getting interrupt at 5ms. Are you sure this is the interrupt you are getting from ADC, not the timer where you configure for 5mS interrupt? Can you try to set a pin in the timer interrupt and clear that pin in the ADC sequencer 1 interrupt. Measure the pin's high pulse with hardware average disabled and hardware average of factor 8?

 I hope this diagram will illustrate how it works. Note the diagram is not drawn to scale. 

Hi Chris,

Christoph50 said:

-> i use a timer for triggering the adc conversion (ADC_TRIGGER_TIMER) with a sample rate of 200Hz (5ms)

Please read Ralph's last post again as he states GPTM only starts a sequencer sample period and ADC clock speed handles the oversample time. Those X's in Charles diagram to me represent FIFO serial bit clock times in the analog signal relative to oversample periods prior to conversion (complete) interrupt. The sequencer FIFO is circular loading 12 bit registers in serial bit times based on sample clock speed (rate) into each steps specified channel. So the ADC sample clock speed as CB1 earlier pointed out is very important to confirm it running at the correct frequency.    

Charles can correct me if not true,  ADC0/1 uses SYSCLK only to configure peripheral behavior and sequencers steps via the registers.

Hi Charles,

Your diagram color flags state conversion time but does not Tc remains 1us for all oversample rates? CB1/ I went round on this some time ago but think he was correct, Tc remaining static time. The FIFO averaging engine adds hardware time based from sample clock rate irrespective the FIFO final results data conversion time. Would it not more properly be called over sample time versus conversion time?

Hi BP101,

  What I wanted to show in the diagram is the difference in conversion time between 1X oversample vs 8X oversamples for each channel in a sequencer. If you program 8X oversample then the sequencer will take 8 times the sample of each channel and average out the conversion result before saving the converted data to FIFO. What I really wanted to demonstrate is that with 8x oversample it will take 8x amount of time to complete the 4 channels in the sequencer. The interrupt is generated after all 4 channels in one sequence has finished. You are correct that with 8x oversample, it still takes 1uS per sample but for 8 samples it will take 8uS (suppose 16MHz for ADCCLK). 

Hi Charles,

now everything is clear to me :-)

i tried the following (like you wrote)...

-> use ADC Trigger source: ADC_TRIGGER_PROCESSOR

-> In the timer interrupt (5ms) routine i call ADCProcessorTrigger(ADC0_BASE, 1) and set an output pin

-> in the ADC sequencer interrupt routine i cleared the output pin an measured the high time of the output pin

==============

-> i saw that the ADC always samples with 1Msps (wasn't clear to me)

-> If i changed the sample rate in the ADC_O_PC register then the measured time changed accordingly -> so Hardware Averaging definitely works :-) !   (things work like that you posted in your picture)

-> But one more thing i -> if i use the function ADCClockConfigSet for changing the sample rate  this didn't 't work -> instead of this i had use HWREG(ADC0_BASE + ADC_O_PC) = (ADC_PC_SR_1M) directly -> then it worked

Thanks a lot for very good support!

chris

Indeed - vendor's Charles provided most excellent (ongoing - and highly detailed) support.      Very good that!

However,

Christoph50 said:

If i changed the sample rate in the ADC_O_PC register then the measured time changed accordingly -> so Hardware Averaging definitely works :-) !

You are - most likely (only) partially correct in drawing that conclusion:

• indeed you've confirmed that the Hardware Averaging performed as expected - 'timewise.'
• yet - if (as expected) you presented a (near constant) signal level to that ADC channel - you have 'NOT' confirmed that (any) 'signal averaging' had occurred!

Such proves so as the 'results' - achieved either 'with or without' HW Averaging - under (near constant) signal level - will  prove 'near identical.'     Thus preventing proper (conclusive) analysis.    

To (really) confirm that HW Averaging works - the input signal should 'vary' during the ADC Conversion 'window.'     For example - assuming an 'over-sample of 8' - with the first 4 input signal levels 'equal & set to 2V5 (2.5V)' and the last 4 input signal levels 'equal & set to 1V5' - the HW Averaging 'result' - (when and if  proper) reveals '2V0.'    (thus - a real 'HW averaging' - has been achieved - and ONLY NOW - confirmed!)    

Minus that  added 'analysis rigor'  -  it proves premature to 'claim HW Averaging to have succeeded' - especially to claim that it,  'definitely works/succeeded!'

For completeness - there remains 'conflict' between poster's (original) goal of  '200Hz'  sampling rate - and the now (listed)  '200Hz/8'  rate!      HW Over-sampling CAN achieve that (originally desired) sample rate by,  'Multiplying the 'ADC-Triggering Timer's' rate - by the  'HW Over-sample's value' - or just slightly above.    (to allow for 'housekeeping/other factors'...)

Hi all,

 I hope this clarifies better than the last diagram how Oversampling works.

Charles Tsai said:

You are correct that with 8x oversample, it still takes 1us per sample but for 8 samples it will take 8uS (suppose 16MHz for ADCCLK). 

That would be contrary to what CB1 and I were debating some time ago in forum.

Perhaps you meant to say 8us for 8x oversample + 1us for the final conversion. Seemingly 8x over sample would require 8 x 12 ADC clock ticks for shifting 12 bits into any (single) sequencer FIFO + TL500ns. Datasheet does not make a distinction between sample time and conversion time but technically the two words have different meanings.

Example: A single 30Mhz clock tick 33ns * 12bits shifted into FIFO or 400ns x 8 over samples = 3.2us + 1us conversion gives 4.2us for a single sequencer step.

Hi BP101,

 Can you please look at my updated diagram?

 Several excerpts from various documents.

 From Drivelib user's guide.

Hardware oversampling of the ADC data is available for improved accuracy. An oversampling factor
of 2x, 4x, 8x, 16x, 32x, or 64x is supported, but reduces the throughput of the ADC by a corresponding
factor. Hardware oversampling is applied uniformly across all sample sequencers.

Enabling hardware averaging increases the precision of the ADC at the cost of throughput. For
example, enabling 4x oversampling reduces the throughput of a 250 k samples/second ADC
to 62.5 k samples/second.

From datasheet:

Up to 64 samples can be accumulated and averaged
to form a single data entry in the sequencer FIFO. Throughput is decreased proportionally to the
number of samples in the averaging calculation. For example, if the averaging circuit is configured
to average 16 samples, the throughput is decreased by a factor of 16.

Yes, that is what I meant to say in the latest diagram. Shown again.

The clarity & effort - displayed w/in Charles' latest drawing - MUST receive high applause.      (even from - this carpal-tunneled - forum reporter...)

May I note three (still) open items:

• Any of this topic's 'ancient history' - presented here/elsewhere - surely must 'GIVE WAY' to the recent drawings & narrative presented by vendor's Charles.    Simply terrific!
• client poster's claim of, 'Definitely Works' has NOT been proven!     Unless he expressly provided an appropriate input signal - (which remains highly doubtful) - no proof has arrived verifying that ANY 'Signal Averaging' - had indeed occurred!    (the application of a 'near fixed level' signal - which is 'easy' (thus expected) is incapable of  establishing that such HW Averaging (really) occurred!)
• The simple act of, 'Multiplying the 'ADC Triggering Timer's' frequency - by the HW Over-sample's value - enables the maintenance of the (originally sought) conversion rate.    Even if - and especially if - HW Averaging has been invoked...   (Note: a 'weasel factor' must be added - some (very) high conversion rates - may preclude the 'maintenance' of  such high conversion rates - under HW oversampling.)

The required 'fine detail' - presenting a method by which, 'HW Averaging's' (actual) impact upon the resulting conversions could be gleaned - arrived here w/in the 02:xx time-frame - earlier this morning.    Is it somehow possible - that the 'assumed accuracy' of such 'HW Averaging' - proves (at least) as important - as its (realized) conversion speed?    That fact has been (conveniently) bypassed - yet proves VERY REAL!

BP101 said:

The block diagram Fig 15-2 indicates the averaging takes place outside the converter but should we take that figuratively to infer it is not part of the converter?

The averaging is done outside the converter.

BP101 said:

Oversampling of signal acquisition points X (Fig 15-6) seems to join the serial FIFO into the AD converter. Does the sample actually need to be fully converted in order to achieve varied acquisition points in ADC clock times to achieve mobility in later acquisition points of the very same signal.

 Yes, each sample result will be first stored into a 'digital' accumulator. The final result of the accumulator is then divided by the number of samples before saving the final average value to the FIFO. The reason to only support average factor of 2, 4, 8, 16, 32, and 64 is to simplify division. No divisor logic is needed. You simply right shift the accumulator by 1, 2, 3, 4, or 5 bits. 

BP101 said:

Otherwise it seems the ADC block perhaps uses SYSCLOCK for the circular FIFO and AD conversion but has not made any clock source shown in Fig 15-2. What exactly is meant by sample clock as it relates to FIG. 15-7?

ADC converter the 'analog' component as shown in Fig 15-7 runs off of the ADCCLK.

Everything else you see in the Fig 15-2 is the ADC controller logic which is 'digital' and they all run off of the SYSCLK. 

This means there must be some synchronization when data is crossing different clock domains. For example, when you receive a trigger from the timer, PWM or etc the controller must synchronize that trigger from SYSCLK to ADCCLK domain. When the ADC finish the conversion, the 12-bit result must go through synchronization from ADCCLK to SYSCLK.   I'm not surprised the synchronization take up some SYSCLK cycles here an there. 

  The min NSH is 4 ADCCLK cycles and the conversion takes 12 ADCCLK cycles and that gives 16 ADCCLK cycles for the Tc. With ADCCLK=16MHz that translates to 1Msps or 1uS Tc conversion time. This is the theoretical conversion rate excluding the synchronization I just mentioned and other latency. In the Electrical section, there is a TLT (Latency from triggger to start of conversion) which is 2 ADC clocks. 

Hi Charles,

Never hurts to check the clock math to confirm ones findings.

Charles Tsai said:

. In the Electrical section, there is a TLT (Latency from triggger to start of conversion) which is 2 ADC clocks. 

Yet odd the sample window being described as fixed time frame, e.g. trigger to conversion ACDCLK @32Mhz gives TLT 62.5ns. Where did the other 500ns in 1us TC go?

Charles Tsai said:

  The min NSH is 4 ADCCLK cycles and the conversion takes 12 ADCCLK cycles and that gives 16 ADCCLK cycles for the Tc

It seems the TLT value explanation attempts to include sample window into TC value without regard for NSH default value. Conversion of 12bits taking 12 ADCCLK cycles seems appropriate yet were is the oversample accumulator located, in SRAM space? Its not using sequencer FIFO but for the final converted result. So accumulator might from datasheet limited explanation be analog based, space charge barrier regions in silicon that hold over sample charge time frame on the Cadc caps.

If a parallel accumulator for all sequencer channels, seemingly the converter clock must be 12x analog sample bit rate or ADCLK @16Mhz requires 192Mhz or faster converter. Point is the sample window time seems to be missing from the TC explanation when hardware averaging seems to first require conversion to digital

Hi BP101,

 As suggested by Ralph, if you have new questions that deviates from the OP's question please create a new thread.

BP101 said:

Yet odd the sample window being described as fixed time frame, e.g. trigger to conversion ACDCLK @32Mhz gives TLT 62.5ns. Where did the other 500ns in 1us TC go?

  The TLT is specified in terms of ADCCLK cycles, not absolute time regardless the ADCLK is 16MHz or 32MHz. I don't understand what you are referring to when you said 'Where did the other 500ns in 1us go'. For 32MHz the Tc is 500ns or 0.5us. There is a 125ns Ts for which to be met by NSH=4. 

BP101 said:

It seems the TLT value explanation attempts to include sample window into TC value without regard for NSH default value. Conversion of 12bits taking 12 ADCCLK cycles seems appropriate yet were is the oversample accumulator located, in SRAM space? Its not using sequencer FIFO but for the final converted result. So accumulator might from datasheet limited explanation be analog based, space charge barrier regions in silicon that hold over sample charge time frame on the Cadc caps.

  The accumulator is nothing but a register implemented in flip-flops. I'm drawing a high level diagram based on my learning from the computer architecture course, well a long time ago. The right shift logic is a way to implement the divider. In real hardware design the shift is a matter of shuffling wires. i.e shift by 0 will be MSB:0 and shift by 1 will be MSB:1 and shift by 2 will be MSB:2 and so on. 

Hi Charles,

Your diagram, WOW forms good part of the nitty gritty missing in datasheet, accumulator being digital.

Perhaps the DQ flops are coupled to the TSN capacitor hold times and form over sample multiples of the TSN acquisition time frames. That was sort of my point that there seems to be missing time as it relates to TSN value as it relates to a GPTM triggering start of sample.

That's why we use TnOTE bit with GPTM one shot to trigger the ADC sample event. Lastly reload the down count of one shot GPTM inside interrupt handler. That seems the most prudent way to ensure the synchronization of SYSCLK to ADCCLK when NVIC is involved. Yet even that is not full proof though a goof step in the measure of timed ARM progress

Otherwise the alternative is to reload GPTM one shot prior to the start of an ADC trigger event with TnOTE bit is set to trigger a specific sequencer, one sequencer and the same sequencer only! No other sequencers (by law) can be triggered!

Hi Charles,

The other point that was not so clear you touched on in your most recent post; electrical section does not indicate NSH being a factor directly linked to Ts by way of a foot note. The over sample bit rate will vary Ts (125n/250ns) as we multiply the number of ADC clocks by NSH cycles.

So Tc is not always 1us and the oversample rate increases Tc by a factor of (Ts * NSH). The FCONV below only determines the conversion bitrate and does not produce or show a new period Tc links to NSH cycles in Tables 15-4/5. Would be helpful to include Tc for the NSH cycles in both tables. That missing info (tables) leads most posters to assume Tc is always 1us as shown in electrical section ADC specifications. Table addition would indicate as troughput or bit rate drops, Tc increases.

k. ADC conversion time (Tc) includes the ADC sample time (Ts).

Bit rate formula leaves out Tc factors:

FCONV = 1/((NSH + 12)*TADC)
where:
■ NSH is the sample and hold width in ADC clocks
■ TADC is the ADC conversion clock period, which is the inverse of the ADC clock frequency FADC

What is the inverse of the ADC clock frequency?