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.

ADC samples very spiky with TM4C1294XL

Hi,

I get very "spiky" ADC sample results using TM4C1294XL. I try using sequencer 3 and also 0 but with the same results, ADC0 , AIN9/PE4. To avoid external noise on Launchpad  TM4C1294XL  PE4 grounded by jumper-wire. I get results : 0,2,0,0,31, 0,0,0,0,0,0,0,10, 39, 0,0,0,0....  . I came from 8 bit word (Microchip) and I'm a bit confused. VDDA ->3.3V, GNDA -> GND , 12 bit 4096 resolution , single ended. Pls some help.

void
ConfigureADC0(void)
{
// Enable clock to ADC0.
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

// Configure ADC0 Sample Sequencer 3 for processor trigger operation.
ROM_ADCSequenceConfigure(ADC0_BASE, 3, ADC_TRIGGER_PROCESSOR, 0);

// Configure ADC0 sequencer 3

ROM_ADCSequenceStepConfigure(ADC0_BASE, 3, 0, ADC_CTL_CH9 | ADC_CTL_IE | ADC_CTL_END);

// Enable the sequencer.
ROM_ADCSequenceEnable(ADC0_BASE, 3);

// Clear the interrupt bit for sequencer 3 to make sure it is not set
// before the first sample is taken.
ROM_ADCIntClear(ADC0_BASE, 3);
}

void
WaitAndReadADC(void)
{
uint32_t  pui32ADC0Value[1];

// Take a  reading with the ADC.
ROM_ADCProcessorTrigger(ADC0_BASE, 3);

// Wait for the ADC to finish taking the sample
while(!ROM_ADCIntStatus(ADC0_BASE, 3, false))
{
}

// Clear the interrupt
ROM_ADCIntClear(ADC0_BASE, 3);

// Read the analog sample
ROM_ADCSequenceDataGet(ADC0_BASE, 3, pui32ADC0Value);

// Update
// the global variable.
g_i16MBMultiple_registers[0] = pui32ADC0Value[0];

}

int
main(void)
{

uint32_t  ui32Count;


uint32_t ui32User0, ui32User1,ui32IPaddr,ui32NetMask,ui32GW,i;
uint8_t pui8MACArray[8];
uint32_t broi=0;


// Make sure the main oscillator is enabled because this is required by
// the PHY. The system must have a 25MHz crystal attached to the OSC
// pins. The SYSCTL_MOSC_HIGHFREQ parameter is used when the crystal
// frequency is 10MHz or higher.
//
SysCtlMOSCConfigSet(SYSCTL_MOSC_HIGHFREQ);

// Run from the PLL at 120 MHz.
g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480), 120000000);

// Configure the device pins.
PinoutSet(true, false);

// Configure UART.
UARTStdioConfig(0, 115200, g_ui32SysClock);

// Configure SysTick for a periodic interrupt.
MAP_SysTickPeriodSet(g_ui32SysClock / SYSTICKHZ);
MAP_SysTickEnable();
MAP_SysTickIntEnable();

// Set the interrupt priorities. We set the SysTick interrupt to a higher

// priority than the Ethernet interrupt to ensure that the file system

// tick is processed if SysTick occurs while the Ethernet handler is being
// processed. This is very likely since all the TCP/IP and HTTP work is
// done in the context of the Ethernet interrupt.
MAP_IntPrioritySet(INT_EMAC0, ETHERNET_INT_PRIORITY);
MAP_IntPrioritySet(FAULT_SYSTICK, SYSTICK_INT_PRIORITY);

ConfigureADC0();

// Take an initial reading of the AIN9
// store in g_i16MBMultiple_registers[0]
WaitAndReadADC();

while(1)

{
WaitAndReadADC();

// Display the SysClock and AIN9 (PE4) digital value on the console.
UARTprintf("AIN9 = %4d\r", g_i16MBMultiple_registers[0]);

SysCtlDelay(SysCtlClockGet() / 12);

}
}

  • A few notes:

    • I don't know about the '129 but the '123 specs the offset at +/-15 counts on the A/D That's probably not what you are seeing but what you are seeing is not much outside that spec.
    • The reference is source from the DC supply and so is sensitive to noise on that supply.  1 count is 1 in 4096 or .02% or 0.8mV.  It doesn't take much noise on the analog power supply, ground or reference to get a few counts.
    • These are fast clocking processors, there's a lot of digital noise around to feed into the analog system.
    • Even ground has an impedance when sinking or sourcing.
    • (4096-40) = 4056 works out to 11.98 bits

    Robert

  • Mile Atanasovski said:
    SysCtlDelay(SysCtlClockGet() / 12);

    Was not, "SysCtlClockGet()" declared, "out of bounds" for this MCU class - and/or this rebrand SW package?

    Most any mixed signal device will prove sub-optimal in its analog role.    I'd be surprised if you can realize beyond 9 "real" bits of ADC data.

    And - might the simple "grounding" of the ADC input be "outside" the required input match - demanded by the MCU's ADC?

    Even unrealistic expectations deserve (some) realistic device spec compliance....

  • Thank you Robert,

    I see your point. Do you have some suggestion for increasing accuracy, for example decreasing sample rate (It's slow process, no need for fast sampling) ?

    Mile 

  • Thank you,
    Maybe the last solutions is hardware (I will lost some analog channels) or software averaging. Is it possible to decreasing sample rate with ADCClockConfigSet(ADC0_BASE, ADC_CLOCK_SRC_PLL | ADC_CLOCK_RATE_FULL, 24);
    and how deep I could go ?
    Mile
  • To the top of this forum appears a thread, "Tell TI" in which both Robert & I have suggested that greater detail be provided in describing the proper "care/handling" of analog signals - prior to their introduction to MCU, ADC inputs.

    Beyond that thread - Robert/I/few others have written here to that subject.    Forum searchbox (wide box, atop this page) warrants your entry of, "ADC input handling" (or similar).

    Analog often proves more complex than digital - again Robert/I agree that analog signal seminars - regularly provided by this vendor/other analog specialty firms - are, "worth their weight in gold."    (yet often require few - or no - gold bars for attendance) 

    You've got to give the MCU's ADC peripheral the "best chance" to succeed - alternatively you may investigate "dedicated ADCs" - which avoid or substantially reduce - the harmful effects of noisy digital signals upon pristine (and demanding) low level analog ones...      MCU as "kitchen sink" proves not always, "ideal" - yet may be adequate - you've not (greatly) detailed your analog use-case...

  • I'll echo cb1s comments about care and feeding of ADCs and recommend again the analog interfacing session offered by several manufacturers, and our previous discussions.

    Now to your question.  You asked about increasing accuracy but what you are measuring does not indicate any accuracy issue, it does show a possible noise issue. Also as I indicated earlier it's not suggesting that the signal is worse than 11.98 bits, pretty good for a 12 bit system. Although given the measurements so far that assurance is not worth a lot.

    There are multiple characterizations of an A/D subsystem.  To narrow to the few that are confused with accuracy there is

    • accuracy, how closely the result matches the actual
    • noise free, how much random noise there is around the value
    • precision, how finely you can measure
    • linearity, how close to a straight line relationship the signal and the measure is
    • repeatability, how well the measure can be repeated

    What you have measured is noise at one value, not accuracy.

    Accuracy using the micro's ADC subsystem will be limited by

    • the ADC reference, often the power supply which is usually 5-10%.  For this reason signals that vary with the power supply are often good sources for micro based ADC systems
    • the source impedance
    • the interface circuit, usually good for 1-2%, but can be much worse
    • the ADC subsystem itself (read the datasheet)

    Minimal noise and reasonable precision is a lot easier to achieve than accuracy. The very first question you need to ask is how accurate do you need the measurement to be. I've found for many systems 8 bits is all the accuracy that is really required and in some cases even 4 would be sufficient. Feedback systems often need precision and repeatability with minimal noise but accuracy may not necessary.

    Robert

  • Thank you for your help,
    I added a hardware oversample and I get what I want.
    ADCHardwareOversampleConfigure(ADC0_BASE, ADC0_OVERSAMPLE_RATE); // where ADC0_OVERSAMPLE_RATE=64 , 64 is a maximum value

    Mile
  • While "hardware oversample" tends to smooth - you trade, "Speed of conversion" for that smoothing.  

    Such may - or may not - be acceptable and is always dependent upon the application's requirements...   And - as the market pushes to faster conversions - you've run counter to that trend.

    While oversample will "cluster" your results - it will not "improve" them.   The proper, "care/handling" of the analog signal - pre MCU introduction (as mentioned by Robert & myself) deserves (some) consideration.    (always silent - thus far - your writings)

  • Just be careful you don't lose what you need in the process.

    Robert
  • Robert Adsett said:
    Just be careful you don't lose what you need in the process.

    Robert - again SO true - and the enforced loss (as you surely know) - of each/every aberrrant reading - may not serve poster's best interest!    In those "illegal readings" may be real GOLD!    Knowing, "when, where, who,& what" leads (most often) to a faster, easier & more precise issue diagnosis.   Instead - if those critical readings are "smoothed into oblivion" their value is lost...

    Might there be a work-around - achieving both poster's desire to "smooth" - but not trashing those "out of spec" readings?    Perhaps the "test of each/every ADC reading" - and the safe storage of those "outside pre-set limits" still enables the H'W oversample - but captures & notifies the program and/or user that something is amiss...

  • Robert Adsett said:
    I'll echo cb1s comments about care and feeding of ADCs and recommend again the analog interfacing session offered by several manufacturers, and our previous discussions.

    Further to that, while looking for inspiration for a related issue I stumbled across a PDF of the book handed out in one of those seminars.

    www.ti.com/.../slap104.pdf

    Worth reading for a good introduction.

    Robert

  • Robert Adsett said:
    I stumbled across...

    Surprisingly often - such, "stumbles" yield real gems.    Yet - in retrospect - was yours (really) a "stumble?" 

    Instead - were you not, "active, alert, and - on the prowl."    Good "luck" (fortuitous stumble) lands often @ the intersection of, "effort, knowledge & awareness!"

    Thank you for that neat link.