TM4C1290NCPDT: Problems reading AIN16-AIN19, PK0-PK3

It is not a known issue with the TivaWare drivers. Are you running under FreeRTOS? If running TIRTOS I can transfer your question there, but I do not support FreeRTOS on this device.

Unfortunately I'm using FreeRTOS... Thanks for letting me know re it not being a known issue. I guess I will try to create a minimal example without any RTOS, unless someone else has any suggestions. 

The fastest & easiest means to gain critical insight when an entire "Group of ADC signals fail" is by:

• first confirming that signals w/in that 'group' are w/in the ADC's input specifications (level especially) & 'reasonably' match the ADC's input impedance at frequency
• once the above is confirmed (i.e. signals are w/in the ADC's spec) then attention must turn to "Set-Up & Config. of the ADC software"

This method has the advantage that SW analysis or change is not initially required.

Follows the "How to" achieve "Quick/Eased" test of the "Failing Group of ADC Signals."     (for device survival - these signals should be measured to confirm they are w/in ADC specs (especially level).)

• temporarily remove the input signal from (one or more) "Known Good/working" ADC Inputs
• and then - route one of your (currently) failing ADC signals (being input from "PK0-PK3") to that "Known Good/working input."    (now 'absent' its original (working) signal)

Should the "new/swapped" signal then "read to expectations" it is likely:

• there is a set-up and/or configuration issue w/your "PK0-PK3" ADC inputs
• there may be routing and/or "signal input match" issues resident upon "PK0-PK3"

Should the "new/swapped" signal then "Not read to expectations" it is likely:

• there are issues w/the signal's level or "signal input matching" which must be corrected

All custom boards prove suspect -  should an "unpopulated board" be available it should be probed to insure correct & successful (PK0-PK3) trace routing.

Hi cb1_mobile thanks for your response. I did not indicate this, but we did a test similar to what you advise. We manually changed the inputs for every signal and looked at the ADC reading in our code. All but the AIN channels mentioned (AIN16-AIN19) correctly followed the applied external voltage. The problem channels did not change, and instead appeared constant. This is not exactly what you are suggesting but I think addresses the same question.  (The electrical connectivity has also been checked.)

Re custom boards being suspect, I appreciate that is the needed default response from a support POV. Alas there is no eval board with the part in question (and I just have a TM4C4C123GXL board handy.)

thanks 

peter

Thanks. FreeRTOS doesn't supply any ADC interface, for that I'm using Tivaware. I will try your test program and then get back to you. At first blush I don't see anything different about what you did vs what I did.

Thank you - issues such as yours present an interesting challenge.

We cannot tell if you, "Re-routed (any) of the failing signals" into known good (i.e. lower numbered ADC channel pins) as we suggested.    At minimum - such confirms that the signal level, ground reference & input impedance are 'reasonable/acceptable.'     May we ask again that this task (even w/only a single 'failed channel') be executed?

We note that even though Ain16 resides w/in a different sequence - it too is reported as failing.   (We'd not expect that.)     However - all of your "failing" analog channels are resident upon Port_K - have you fully & properly enabled Port_K & then commanded PK0-PK3 as ADCs?    (we note that the code you've supplied avoids including the (necessary) low-level initializations - leaving "Failed Port_K Initialization" as "Highly Suspect!")

This MCU supports 20 ADC Channels (ranging from Ain0 - Ain19) - yet your four sequencers range from Ain0 - Ain20!.    (we suspect one of those channels is the internal die temperature - yet the code snippet linked is not sufficiently detailed to illustrate and/or assure that.)

Your re-purposing the ADC Sequencers is inventive yet somewhat 'unusual' here.    And that insight leads to further (eased) suggestions.

• Kindly bypass/disable (i.e. comment out) your  "void initADC0FirstSequence()" - enabling only then "void initADC0SecondSequence()."    (this attempts to determine if the "Switch between sequences impacts your issue.")
• Should that implementation fail - kindly install the code w/in your "failing" Second Sequence - in place of (i.e. swap the code) the (almost) working code w/in the First Sequence.   (works but for Ain16.)     In this case bypass/disable the Second Sequence.    (the aim here is to "Attempt to benefit from the First Sequence's success - yet w/your "flawed channels" now being exercised.)

It is hoped that you'll give these suggestions a "Fair (unmodified) try" - we've co-founded, then taken tech firm public via similar methods ... have (often) succeeded thru methodical, focused, inspired diagnostics...   

Dear cb1_mobile thanks again for taking the time also including the time to look into the code link! Much appreciated.

I will try to do your proposed test ASAP. I thought by directly applying a voltage to the AIN16-19 inputs and seeing no changes to the read-out value would effectively probe the same thing.

The initialization is spread out over a few different areas, unfortunately. The pins are set in a file that I directly generate from TI PinMUx tool [a]. The ADCs themselves etc are initialized in a system init function that is called before the RTOS starts which is located at link [b] . I also initialized PK4-PK7 as GPIO pins in link [a]. I kept the pinmux output as the tool generated it so that I can replace it easily if I need to redo the pinmux assignments. but it leads to code being spread out over a lot of places.  

Re sequencers, if there is a different way to do this that is less 'inventive' and more standard I'd be happy to change the code. I agree that what I did is somewhat awkward.

I'm away from my lab today due to a snowstorm but will try your suggestion ASAP. Thanks again for taking the time to help me.

-Peter 

[a]

[b] 

Thank you - such "meaningful, detailed & agreeable" response much appreciated.     (Often young staff/I are 'attacked' for not (blindly) agreeing w/poster's (pardon) "bit-hazy" (i.e. guessed) solution analysis.    As stated - we've many (successful) years in the Diagnostic Trenches...)

The sequence & deliberate test we proposed:

• assumes little
• probes to 'tease out' what works - and does not - w/the minimum of (unwanted) code or circuit interactions

It will prove useful to receive your results when the snow recedes.     Our concern is that your "Set-Up/Confg. of Port_K" - especially its ADC functionality - may be compromised.    Applying a voltage to PK0-PK3 - as you've done (outside our directive) fails to deal w/any Port_K SW issue(s)...

My small tech team 'buys in' to "KISS."    Simplification limits the "Field of Battle" - thus better (and faster) exposes (both) errors and their sources.   We'd like you to:

• follow the helpful code input provided by vendor's Bob - yet extend it to 'all' of the failing PK0-PK3 pins
• temporarily dismiss/disable your existing Four ADC Sequencers  (commenting out illustrates one means)
• employ only a single sequencer - using only PK0-PK3 at their (unchanged/original) MCU pin locations

This aims to determine if:

• an ADC Code Error (likely set-up/config)
• and/or your (unique) 'toggling of ADC Sequencers'

serves as the "Guilty Party."    Again - ONLY one sequence is to be run!

Should this fail - those MCU ADC pins (PK0-PK3) - may (somehow) have issues.   (or extraneous components, routing defects etc.)    In this (failed case) of the above - kindly:

• remove the signal inputs from your "known good" (working) ADC Channels  (w/in the simplest sequencer)
• replace those w/the signal inputs (currently) routed to PK0-PK3
• make NO Changes to the software of that (working) sequencer - all we are changing is the "signals being introduced!" (PK0-PK3)

This aims to determine if those 'signal inputs' are proper (i.e. w/in MCU Spec).    (this proves effective as the "Set-Up/Config" of this "proven good" sequencer is UNCHANGED! ... the software does not care from where the signal originates...)

Friday is our busy (i.e. shipping) day - we'll be unlikely to review your new files till post shipping - late this afternoon (early evening)...   (We'll edit this post after reviewing your newly arrived files...)

Or not - kindly see following post...

Several of my team reviewed your code - while we (almost) understand your justification for such, "Code Distribution" (pardon) it becomes a "nightmare to review!"    We find that such "unexpected distribution" of key code elements - w/in (normally) "dedicated code blocks" (yet now "highly scattered & unlinked") borders upon, "Krazy Making!"

Our deep dive into your code revealed:

Good:

• you had properly enabled Port_K and both ADC Modules (0 & 1)
• you had configured those "errant Port_K ADC Inputs."  (PK0-PK3)
• you followed the DRL's instruction to "Disable the ADC Sequencer prior to configuring it."    (another's code offering here (pardon) missed that!)

Unknown:

•  your code did not clearly reveal, "If you had properly waited until the sample sequence had completed - prior to reading the ADC."

Not Good:

• you dd not, "Await the ADC Module's becoming ready - prior to configuring - via SysCtlPeripheralReady().

This 'deep dive' into your code (investigation) failed to determine, "How & Why ADC inputs "PK0-PK3" were reported as 'failing.'   (our earlier direction provided an advantaged sequence of disciplined tests - designed to 'tease out' the cause of those failings...)

Again - your, regular, "Re-Programming of the ADC Modules" - such that they'd accommodate different ADC Channels at different times - (may) have "invited in programming issues" - not normally encountered.   As we are w/out (any) '129 family devices (we have the Need for Speed) - we cannot test/experiment on our own...

Now there exists another means for you to achieve, "Twenty ADC Channels" - while avoiding the (potential) for "Re-Programming Induced - ADC Sequencer Issues!"   Could you not:

• employ 8 unique channels  via ADC_0's Sequence 0
• and an additional unique 8 via ADC_1's Sequence 0
• and 4 more unique via ADC_0's Sequence 1.   (that reaches 20 channels!)
• and yet another 4 - via ADC_1's Sequence 1.   (now you've created a 'swamp')

We believe this method eliminates many/most (perhaps all) of the complications which "Sequencer on the Fly Re-Programming" - may introduce.

[edit] 07:29, 08 Feb 2020:  We recognize that your ADC Sequencers were (likely) "populated to accommodate execution ease & speed."    Our method (as above) targets "Potential Issue Mitigation" - which must always precede "optimization."    Premature optimization is the cause of (much) programmer "Pain & Suffering" - and should be attempted (after) the program's mission has been achieved...

Follows several of these (potential) "On the Fly - Sequencer Re-Programming Issues:"

• Once any of the sequencers have completed their code routine - they are NOT expressly disabled!    This (may) create the means for 'mischief.'
• Each/every one of your sequencers is "Triggered by a Repeated and Common Trigger!"    (i.e. ADC_TRIGGER_PROCESSOR!)    How likely is such "Common Trigger" to cause mischief?
• And - how does the RTOS impact any of the above?

My small group remains convinced that our, "Earlier identified tests should be performed first" - results reported - and then (as/if necessary) the suggestions herein (this post) considered...