TM4C1294KCPDT: ADC0 FIFO clocking array timing

Notice the red box in above Widget capture the signal has differential character and shoots more negative when the other steps 1,2 did not. Notice too there seems to be a lot of differential low level noise riding on the FIFO data between my pin sticks into each input. Odd thing is all AINx channels are configured as single ended.

Have lately wondered how differential pin configurations in the analog MUX may be some how to blame. Yet CCS debug shows the sequencer 1 step 0 was configured correctly.

BP101 said:

signal level of each step (2nd capture) appears to grow as I move a stick pin among 3 ANIx inputs  .... The stick pin acts as a  low cost sinusoidal 60Hz analog signal source

Be still - (very still) - my heart!    Can you say, 'Spare NO EXPENSE' in deploying the most appropriate of 'Test Equipment?'

You do realize that you (still) owe Vendor's Bob 'Three Answers' - and especially his quote, "I suggest you use a function generator and apply a 3V sine wave (0 to 3V) at 20KHz to one of the inputs. You should then see the sinusoidal pattern repeat every 10 samples.   If not, we need to resolve that problem before continuing."

Have you not - rather completely - 'Turned your back to Bob's (most valid) suggestion?'     May it be asked, 'Why is that?'    

It has NOT been forgotten - that three answers are owed - are they not?    This vendor has, 'Gone 'SO' Above/Beyond  in your behalf' - should you not  attempt to (somewhat) comply - with his (fairly & logically) presented requests?    

You have (likely) 'Broken (very) new ground' - with this  stick pin  (as test gear) posting...

BTW - I can 'Coach you' in the creation of a "Function-Generator (lite)" - employing (just) a TM4C123!   Such should prove, 'Orders of Magnitude' beyond your (claimed) 'Low cost, sinusoidal 60 Hz' (pardon) 'likely ESD Generator!'    (I doubt that I 'stand alone' - in being 'disturbed' - by such a 'desperate (and highly improper) measure!')

Deflect from the real issues being posted, no matter the posters method proves viable in the process seems the pattern of late. Really can't point individual blame as the MCU appears to have fallen off a truck somewhere between China and Singapore with all it's vast anomaly being revealed of late. Gramps used to say "We only get wiser as the hair grows longer in our nose and ears."

cb1_mobile said:

Have you not - rather completely - 'Turned your back to Bob's (most valid) suggestion?'     May it be asked, 'Why is that?'     And how is he to feel - in light of this apparent - 'diversion?' It has NOT been forgotten - that three answers are owed - are they not?    This vendor has, 'Gone 'SO' Above/Beyond  in your behalf' - should you not  attempt to (somewhat) comply - with his (fairly & logically) presented requests?  

Bobs methods proved to make the matter worse 1MSPS no hardware averaging as last sequencer step signal levels became more distorted and differential without hardware averaging.

cb1_mobile said:

BTW - I can 'Coach you' in the creation of a "Function-Generator (lite)" - employing (just) a TM4C123!   Such should prove, 'Orders of Magnitude' beyond your (claimed) 'Low cost, sinusoidal 60 Hz' (pardon) 'likely ESD Generator!'    (I doubt that I 'stand alone' - in being 'disturbed' - by such a 'desperate (and highly improper) measure!')

The AC signal input has not changed between pins, it being without common ground proves mayhem exists in the analog MUX configuration of the AINx channels. I have a built in 25KHz  PWM generator so that will be the next test but no better to explain why SS1 step 0 is being amplified. The stick pin explains why SS1 step 0 required SW subtracting huge integer value from all steps samples in order to stop over peaking both M3 & M4. So it may very well be Tivaware configuration related analog MUX mayhem to blame.

cb1_mobile said:

You do realize that you (still) owe Vendor's Bob 'Three Answers' - and especially his quote

 Not true, all his questions have been answered yet the most important of my posted questions go unanswered. More deflection by the vendor for symptoms they should have answers for especially why the INA240 signal fails to be properly read by TM4C SAR. The vendor has not stated anything wrong with the signal or how the signal may require certain alteration to achieve an answer to that  simple question.

That said the vendor with all it's sophisticated testing equipment has missed a very important clue as to why so many post this forum ADC step precision seems to fail. Configuring ADC0 for 2MSPS improves sample acquisition granularity, the vendor knows that and fails to explain how the OPEN LOOP GAIN was being increased in all 3 AINx channels.

Simple DMM check AINx channels never crossed our mind as being a necessary test EK-TM4C1294XL. Logically there should be NO floating voltages (158mV) on any AINx sampled pins, let alone discovering cycling voltages, e.g. 602mV cycle down to 0.5mV repeating during idle. That seems more of a MUX issue since there remains sampling of other AINx pins even during idle state. CADC of non sampled channels are charging up and discharging via the 30Megohm DMM load. The initial float level during idle remains above even 602mV, how can that be as the channels were specifically designed to limit cross talk and (BALANCE) them. Stick pin test proves they anything other than balanced in the current Tivaware analog MUX configuration or AD converter to FIFO loading process. 

Fact is testing without hardware averaging discover the limited balance between AINx pins widens in bandwidth (1MSPS), the issue is NOT analog sample frequency related. The FIFO loading sequencer step 0 issue is more closely related to timing of AD converter, e.g. if we were to accept the analog MUX has been properly configured by Tivaware. Disabling sequencer step 0 adds time gap for the AD converter to load the TRUE analog FIFO data. Otherwise circular reading FIFO into specified Array[slots] is kluged by HWREG calls to properly target the FIFO 12bit register data. HWREG loading of circular FIFO data was Stellarisware accepted method to trigger circular reads and should have been fully debugged along the migration path to Tivaware. The very same HWREG MACRO used in Tivaware FIFO reading of sample data function call must not white wash errata by nefarious means without being disclosed in the version Manifest text such errata was being masked or corrected.

Lets assume that posted issue described several different ways to vendors helpers was not masked or white washed via nefarious means or human indiscretion. That again leaves hardware AD converter timing the primary suspect of FIFO data being out of phase with sequencer steps! Admitting a problem exists is always the first step to recovery!

What to (properly) say ... other than, 'Long live (pure & unfettered OPINION) - supported with (ALL) the power/precision of that (renowned)  STICK PIN!

Bob Crosby said:

The total error for the TM4C129 ADC is +/- 30 LSB when it is clocked at 32MHz. (2Msps). The total error is +/-4 LSB when clocked at 16MHz. It is better to do a single conversion at 16MHz ADC clock than to do a 2 sample hardware average with a 32MHz ADC clock. They both take the same amount of time and produce a net sample rate of 1Msps, but the slower ADC clock rate will give more accurate results.

Bob's quote - 'says it all' - and (as usual) is refuted (only) by your (highly suspect) 'opinion.'

Again It ain't the stick pin being the issue of failed AD converter samples via HWREG (properly) reading circular FIFO data in the production system.

Yet the evidence of not 1 but 2 comparative captures prove nothing? Perhaps a self serving DA would go to any length to proclaim posters evidence being admissible for the jury to make up their own minds.

When the (law) is against you - Attack the facts!     When the (facts) are against you - Attack the law!    (first year law-school - prior to 'contract immersion')

Might this be amended (here) to: When the 'Signal/Function Generator' is suggested ... 'whip out' the (classic) 'Stick-Pin.'

And again - you have failed to respond to Bob's three requests!    (instead presenting (yet more) naked opinion - surely achieved via your (unique) brigade of,  'Stick-Pin Like/Inspired'  Test Equipment.

Is it proper to 'endlessly Request Help here' - and then:

• fail to respond to the vendor's direction (presented in high detail - UNIQUELY) in your behalf?
• offer up your (opinion) likely resulting from 'PRISTINE MEASUREMENTS' - clearly gleaned via 'Stick-Pins'  (masquerading as Test Gear) - (chosen & approved by (only) YOU!)

Might you (simply) TRY to (really) COMPLY w/Vendor's focused direction?

cb1_mobile said:

Bob Crosby The total error for the TM4C129 ADC is +/- 30 LSB when it is clocked at 32MHz. (2Msps). The total error is +/-4 LSB when clocked at 16MHz. It is better to do a single conversion at 16MHz ADC clock than to do a 2 sample hardware average with a 32MHz ADC clock. They both take the same amount of time and produce a net sample rate of 1Msps, but the slower ADC clock rate will give more accurate results.

Perhaps you may want to redact that assumption since it has no substance to this post testing being ADC0 1MSPS besides being a mute point for symptoms being posted. Attempting to change the narrative of posters content to suite the vendors perspective far to often seems the primary goal with in this TI community. So far our case has huge evidence of ADC configuration failing within the software HWREG functions of FIFO data of not only Tivaware yet stemming from/into previous versions of Stellarisware! 

The Tivaware  MACRO calls have to properly assert in the compiled object to make the silicon preform not only by directive calls but also to the MCU registers when processed via CPU instructions directly from compiled inline HWREG directives. Testing of Tivaware MACRO directives must achieve the same register functionality as they do when called within a Tivaware function or as inline directives of a subordinate user function. Fool me twice shame on you, fool me six times shame on me!

Only (one) comment remains, God SAVE the Queen! (and too - her entourage of 'high performing' Stick-Pins...)

Bob's 'three unit direction' to you - sought to,  'Establish a 'BASE-LINE' - so that (all that follows) would have some (base) correctness.    

Such is a key aspect of 'KISS' - and when avoided/bypassed - endless: Time, Effort, and Costs may be expended - and 'all results' (remain) HIGHLY SUSPECT!

cb1_mobile said:

fail to respond to the vendor's direction (presented in high detail - UNIQUELY) in your behalf?

• offer up your (opinion) likely resulting from 'PRISTINE MEASUREMENTS' - clearly gleaned via 'Stick-Pins'  (masquerading as Test Gear) - (chosen & approved by (only) YOU!)

Perhaps you have failed to clearly read post being tested 1MSPS actually started 2MSPS. Vendor instructing poster to reduce sample granularity made no difference to the FIFO data being any better or worse from sequencer step 0. Who knew underlying ANIx channel voltage being obscure, no one would ever think to check AINx sampled input floating 150mV. How exactly does that achieve INL of +/1.5 Typ., +/-3 LSB Max unless the ANIx input was grounded.

I don't blame vendors helper in this but perhaps try to think outside your cubical sometimes. Its not the test method that counts rather the results that lead to a solution of recovery being more important. What part of KISS stickpin test is not KISS, keep a simple objective in discovery, less sometimes proves more. KISS administrator so often preaches we KISS our objective. Vendor can even KISS a launch pad via same simple KISS stick pin test, no worse than floating voltage on AINx pins in my opinion. 

BP101 said:

Perhaps you have failed to clearly read post being tested 1MSPS actually started 2MSPS. Vendor instructing poster to reduce sample granularity made no difference to the FIFO data being any better or worse from sequencer step 0.

My understanding is that neither method that you implemented has given you the expected results. I suggest you reserve judgement until your other issues are resolved.

Seemingly the entire issue being the sequencer step sampled, written into specific circular FIFO-1 steps are not always reading the same data being written indicated in the test case above for the same acquisitioned data of SS1 step 0. That can clearly be seen in the cascading sample data of scope widget being excessively distorted in step 0 of sequencer 1.

All three steps of SS1 should have nearly the same data amplitude being returned via scope widget. Clearly that is not the case as the FIFO tail pointer index is likely amuck in the C+ array cell it was supposed to be written into. Highly suspect the head pointer is misaligned with the actual acquisitioned data written into circular FIFO-1 step index pointed to by the head pointer.

So single R/W sequencer operations are marginal when the tail pointer (index) should be 0 in the 1st read of circular FIFO into an C+ array but often data is not pointing to step 0 (tail) index after ready interrupt occurs. We can't trust the circular FIFO has not rotated past a specific index of any single step back to index 0 (as it should) when the END IE are included in the last step or without ANIx source pin being defined in the last step. It should not matter how the last step is configured, the FIFO-1 index should be ZERO upon entering the interrupt handler but clearly is not.