Tiva ADC Sequencer with different step sources

Pablo Rego said:

I have a more complex code where I configure this and other things.

And - it's revealed here - that the "more complex code" does not run/execute to your satisfaction.   Absence of that code does not (readily) enable your remote helpers to diagnose/assist.

Are you aware that the temperature you are measuring is that of the MCU's die - and bears little relationship to the temperature of your board?   The fact that you report widely varying - ADC values (likely) indicates that your packing/unpacking of the step sequencer's values has some issue...

That's a great & quick response - thank you.

Might you detail how you "read" only step 3?   My understanding is that 4 values are converted (based upon your code) and that you must perform 4 "reads" to extract the value harvested by "step 3!"   (it is a bit confusing - suggest that you look @ several of this vendor's ADC examples) - you'll note that multiple reads are required to extract the higher order values from the step sequencer.

Dawns further that if you switch to a single step sequencer - or change your code to just perform a single step conversion - results will improve!

Yes, I read the 4 steps at once, using

ADCSequenceDataGet(ADC0_BASE, 1, ui32ADC0Value);

which is defined as 

uint32_t ui32ADC0Value[4];

But I am only interested in ui32ADC0Value[3], which corresponds to the step 3 measurement.

Here's my belief - if you "float" those other ADC inputs - rather than properly drive them - the ADC's input capacitor may become "disordered" - and that may explain your improper readings.

Some "battle fog" has landed here (22 back-forth) now - have you (really) and properly configured those 3 ADC input pins?   If not - and you then run your (failing) code - bets are "off" on code's success.   You have to be very careful not to confuse ADC Channel Number with MCU pinouts or "step" in the step sequencer...
 
There's a quick/easy and dirty test of my theory - simply tie each of those 3 ADC channels (which precede your temp sense step) to ground - and note (and report) the results...   Bet you that will improve (although may not completely fix) your results...

Still - do keep in mind that MCU's die temp bears little relationship to your board temp - and will change w/System Clock and current draw of your MCU...

Hi Amit,

Re: Always Trigger.

That's great - wager tall stack (black) that you've just "nailed it."

We've never/ever employed, "Always Trigger" and never been so plagued by ADC pointer "running amuck."

In the (unlikely) event that issue remains - I'd apply 4 "stepped voltages" to each of the 4 ADC channels. (do away with "TS" during this test.)

1V0 - 1V5 - 2V0 - 2V5 (that's 1.0 - 2.5V) works nicely for us - and will quickly pinpoint where the conversions are befouled... (we actually have several small pcbs which provide 8 stepped voltages - used for our test/verification.)   By changing the input voltage @ top of the divider - we can "shift" each signal up/down - as/if required...

Hello cb1-,

I will ground those other 3 ADC channels, but I really hope it doesn't work. Look, imagine that you are feeding the board with 3 analog control signals (and the TS); 1 wire cable breaks; and you might have all 4 channels "disordered", breaking also the other 3 channels instead of only one? I would think it could be a major hardware issue in the board's design; this kind mistake I usually don't see my students to commit... Thus I like to think it's a problem in my code.

Hi Pablo,

First - we feel your pain - but you are proceeding in an orderly fashion - that's always good.

I agree w/your assessment of, "ADC's handling/performance" when enabled ADC channels, "float."   May I note that other - ARM MCU vendors - suffer similar limitations?  

My small tech firm believes strongly in KISS - that "stepped input voltage" introduced to all 4 of your (properly) enabled ADC channels (please eliminate the TS during this simple test) will best illustrate any, "Pointer disorder!"   That should be high (imho) on your priority list.

A final point - always distrubing - and a great, "time/effort/money waster" is dreaded, "Single board anomaly!"   Have you a 2nd board with which to duplicate your set-up and test?   Broader findings (always) prove of more interest to vendors (and to outside helpers)...

Final grasp - your MCU system clock must run at (or beyond) 16 MHz for proper ADC operation.

Hello Amit, 

I changed to ADC_TRIGGER_PROCESSOR, but the results did not change (not a slight change). 

The resulting code is

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "inc/hw_ints.h"
#include "driverlib/sysctl.h"
#include "driverlib/adc.h"
#include "driverlib/interrupt.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"

uint32_t ui32ADC0Value[4];

volatile uint32_t ui32TempAvg;
volatile uint32_t ui32TempValueC;

int main(void) {

	SysCtlClockSet(
	SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_SYSDIV_5);

	SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
	SysCtlPeripheralReset(SYSCTL_PERIPH_ADC0);

	ADCSequenceDisable(ADC0_BASE, 1);
	ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_PROCESSOR, 0);

	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
	GPIOPinTypeADC(GPIO_PORTD_BASE,
	GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2);

	ADCSequenceStepConfigure(ADC0_BASE, 1, 0, ADC_CTL_CH7);
	ADCSequenceStepConfigure(ADC0_BASE, 1, 1, ADC_CTL_CH6);
	ADCSequenceStepConfigure(ADC0_BASE, 1, 2, ADC_CTL_CH5);
	ADCSequenceStepConfigure(ADC0_BASE, 1, 3,
	ADC_CTL_TS | ADC_CTL_IE | ADC_CTL_END);

	IntEnable(INT_ADC0SS1);
	ADCIntEnable(ADC0_BASE, 1);
	ADCSequenceEnable(ADC0_BASE, 1);

	IntMasterEnable();

	while (1) {
		ADCProcessorTrigger(ADC0_BASE, 1);
	}

}

void ISRHandler(void) {

	ADCIntClear(ADC0_BASE, 1);
	ADCSequenceDataGet(ADC0_BASE, 1, ui32ADC0Value);

	ui32TempAvg = ui32ADC0Value[3];

	ui32TempValueC = (1475 - ((2475 * ui32TempAvg)) / 4096) / 10;

}

Pablo Rego said:

I see that always 3 values go wandering near 0

Our posts just crossed.   Most any mixed signal ADC will be greatly challenged over 3-4 least significant bits.   If your "wander" is w/in 16 ADC counts - I'd rate that as normal.   (again - this is a weakness of all such MCUs - not confined to this vendor. [we use ARMs from 4 other vendors, too])

Have you changed to, "Processor Trigger" and are you waiting for conversions to be complete?   May I suggest that you re-read and review, "examples/peripherals/adc/"single_ended_adc.c"  (that file name from memory - should be close - there's a wealth of tips contained - that file...)

[edit]  I fly shortly - quick read your (most recent) code does not reveal proper "waiting" for conversions to truly complete!  (well illustrated in "single-ended.c")  Suspect strongly that this could be crucial - again I read code quickly - please check...

[edit]  Alas we crossed (again!)   I see that you have correct system clock & that you are, Processor Triggered - both good.

Now - please take no offense - but your code:

    ADCSequenceStepConfigure(ADC0_BASE, 1, 0, ADC_CTL_CH7); 

    ADCSequenceStepConfigure(ADC0_BASE, 1, 1, ADC_CTL_CH6);

For clarity - here's the relevant portion of file, "single_ended.c"

       // Wait for conversion to be completed.
        //
        while(!ADCIntStatus(ADC0_BASE, 3, false))
        {
        }

        //
        // Clear the ADC interrupt flag.
        //
        ADCIntClear(ADC0_BASE, 3);

        //
        // Read ADC Value.
        //
        ADCSequenceDataGet(ADC0_BASE, 3, ulADC0_Value);

Now this may not be your step sequence - I wanted to highlight the necessity to "wait" for conversions to complete!  Note that ADCSequenceDataGet() is "held off" until the conversion has had time to (properly) compete...

Hi Amit,

May I note that (my) suggested "single_ended.c" AVOIDS the complications you've just identified by sending results via UART?

When KISS is deflected - relatively simple ADC issue extends to 30 (or more) back-forth - "fogs learning" for future readers...  (steers you away from other, more vital issues)

@Veikko,

Tres bien! (that's now TWO for you - w/in same week!)

Everyone here (but for you) missed that.

RTFM (and chip errata) always makes sense. And especially so when problems visit...

Still - that "TS" proves of very limited value - poster has never justified "why" it's a big deal...  (we all may have "chased our tail" for little (end) gain...)

Guys, only for clarification, since we have done so many tests, the updated version of the code is the following:

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "inc/hw_ints.h"
#include "driverlib/sysctl.h"
#include "driverlib/adc.h"
#include "driverlib/interrupt.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"

uint32_t ui32ADC0Value[4];

volatile uint32_t ui32TempAvg;
volatile uint32_t ui32TempValueC;

int main(void) {

	SysCtlClockSet(
	SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_SYSDIV_5);

	SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
	SysCtlPeripheralReset(SYSCTL_PERIPH_ADC0);

	ADCSequenceDisable(ADC0_BASE, 1);
	ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_PROCESSOR, 0);

	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
	GPIOPinTypeADC(GPIO_PORTD_BASE,
	GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2);

	ADCSequenceStepConfigure(ADC0_BASE, 1, 0, ADC_CTL_CH7);
	ADCSequenceStepConfigure(ADC0_BASE, 1, 1, ADC_CTL_CH6);
	ADCSequenceStepConfigure(ADC0_BASE, 1, 2, ADC_CTL_CH5);
	ADCSequenceStepConfigure(ADC0_BASE, 1, 3,
	ADC_CTL_TS | ADC_CTL_IE | ADC_CTL_END);

	IntEnable(INT_ADC0SS1);
	ADCIntEnable(ADC0_BASE, 1);
	ADCSequenceEnable(ADC0_BASE, 1);

	IntMasterEnable();

	while (1) {
		ADCProcessorTrigger(ADC0_BASE, 1);
	}

}

void ISRHandler(void) {

	while (!ADCIntStatus(ADC0_BASE, 1, false)){};

	ADCIntClear(ADC0_BASE, 1);
	ADCSequenceDataGet(ADC0_BASE, 1, ui32ADC0Value);

	ui32TempAvg = ui32ADC0Value[3];

	ui32TempValueC = (1475 - ((2475 * ui32TempAvg)) / 4096) / 10;

}

cb1_mobile said:

Still - that "TS" proves of very limited value - poster has never justified "why" it's a big deal...  (we all may have "chased our tail" for little (end) gain...)

Back in the day when I got my first Stellaris LaunchPad - which was my first touch with an ARM uC btw, it was an easy way to demonstrate that your ADC code works (luckily, I started with hardware averaging = 64, so didn't see the errata'd problem as my first thing) without having to attach anything to the LaunchPad. As for any real use, not much probably - maybe a "free" relative temperature sensor. You could use it to see if the temperature in your case is rapidly rising, for example. Forget it for absolute values.

Pablo Rego said:

I tested the single_ended.c, it works

Indeed - yet many here knew that.   And this verifies that your basic set-up/config is correct/proper.

Nothing prevents you from the simple extension of "single_ended.c" to a larger step sequence.

Far earlier here I suggested that you drive multiple analog channels with known, stepped (proper) voltages.  In compliance w/KISS - that will confirm that some/most/all of your "CUT" (ADC channels under test) work in accord w/your code.   Armed w/that - should you still seek to implement your earlier method - you now enjoy a mechanism to highlight when/where the conversions, "break!"

I think that maybe we turned the problem complex unnecessarily. The problem actually is simple. I have an ADC module, ADC0. ADC0 (as well as ADC1) has the sequencer 1 which has 4 measurement steps, which I can attach each one to a different source, according to the datasheet. So I need to attach 3 analog pins to the first steps, and the temperature sensor to the last one.

So I configured the system clock

SysCtlClockSet(
SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_SYSDIV_5);

After configured and reset the ADC0 peripheral

SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
SysCtlPeripheralReset(SYSCTL_PERIPH_ADC0);

Disabled the sequencer, configured, enabled the ADC0 peripheral, and set the GPIO pins to the ADC type

ADCSequenceDisable(ADC0_BASE, 1);
ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_PROCESSOR, 0);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
GPIOPinTypeADC(GPIO_PORTD_BASE, GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2);

So I configured the steps

ADCSequenceStepConfigure(ADC0_BASE, 1, 0, ADC_CTL_CH7);
ADCSequenceStepConfigure(ADC0_BASE, 1, 1, ADC_CTL_CH6);
ADCSequenceStepConfigure(ADC0_BASE, 1, 2, ADC_CTL_CH5);
ADCSequenceStepConfigure(ADC0_BASE, 1, 3, ADC_CTL_TS | ADC_CTL_IE | ADC_CTL_END);

Enabled the interrupt and the sequencer

IntEnable(INT_ADC0SS1);
ADCIntEnable(ADC0_BASE, 1);
ADCSequenceEnable(ADC0_BASE, 1);
IntMasterEnable();

And in the main while loop, triggered the processor

while (1) {
ADCProcessorTrigger(ADC0_BASE, 1);
}

Also in the ISRHandler I am waiting redundantly for the measurements end, clear the interrupt, and get the data buffer.

while (!ADCIntStatus(ADC0_BASE, 1, false)){};
ADCIntClear(ADC0_BASE, 1);
ADCSequenceDataGet(ADC0_BASE, 1, ui32ADC0Value);

I think the steps above now are correct, but obviously I forgot to include some configuration. Given all the tests we've done, I may have to conclude that it's not a hardware problem, it's not a TS errata or TS specific problem, it's not a capacitance problem. For me it's clear it's a software problem, maybe a Tivaware library registry lack of configuration (I'm using TivaWare_C_Series-2.1.0.12573), or a simple call that I didn't do. So the problem is: where in the code did I miss a configuration?

@Pablo,

Glad that you persisted and resolved issue.   Devil so often in (fine) detail.

May I commend you for thanking (all guys) along w/Amit?   Most here - too seldom - thank Amit - and rarely extend such to "outsiders."

Good for you...