ADC Speed Set

There is missing a 'S' :)

Try out this:

SYSCTL_ADCSPEED_125KSPS

Peter

Thanks Peter, the missing 'S' was only in my message. In the source code it was ok and it didn't work.

I've found something strange. There is an example (Getting Started with the Stellaris® LaunchPad: Chapter 5 Video) that calls this function, but if we look at the same example on TIVA C, is function call has been removed.

May be TI could help us.

You could try ADCHardwareOversampleConfigure() and use hardware oversampling to lower the throughput.

Interesting Zander, I will give the theme a try tonight....

Hello Hailing,

That is a good idea, It indeed reduces the throughput, but in our case, the average associated with oversampling removes high frequency information of the signal being sampled and compromises its integrity.

In one hand, we need to sample the signals with a125ksps due to the fact that they need to be stored in memory for post processing, and in the other hand we cannot average the samples because it might affects its integrity.

Thanks anyway for your suggestion.

Regards,

Zander

Our group has noted similar issues - when (like you) operating the ADC @ lower sampling rates.  And - there is a benefit in so doing - the ADC's input C has more time to charge/discharge - thus reducing the effects of preceding step "signal-bleed/crosstalk."

Here's a method we've found useful: note: I've left function parameters blank - you must match to your set-up... (note - this works with or without your use of ADC Interrupts)

      ADCSequenceEnable();

      // Clear the interrupt status flag prior to any sample.
       ADCIntClear();

        // Trigger the ADC conversion.
        //
        ADCProcessorTrigger();

        // Wait for conversion to be completed.

        while(!ADCIntStatus())
        {
           ADCIntCntr ++;
        }

        // Clear the ADC interrupt flag.

        ADCIntClear();

        // Read ADC Value.

        ADCSequenceDataGet();

       ADCIntCntr = 0;

The while loop in this sequence insures that the ADC completes its task - the counter enables you to determine the "normal" conversion time.

We've used this method w/success many M3s and newer LX4F (may they rest in peace) scrap-heaped family...

Should this not substantially improve - post your ADC set-up/config code - especially noting all ADC Sequences in use...

Hello cb1_mobile,

Your comments  are correct, but our problem was regarded to unexpected behavior after calling function SysCtlADCSpeedSet, when we were programming with TIVA C functions libraries.

Our colleague Peter Krengel found a solution for our problem.

Inverting the order of the functions to enable the ADC and to set the sample rate, the thing works fine with TIVA C. If the ADC is enabled first, the program runs into the ISR fault.

So, the order is:

ROM_SysCtlADCSpeedSet(SYSCTL_ADCSPEED_250KSPS);

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

Tks

Zander,

thats interesting (Stellaris workshop). Anyway, I believe there are problems

with enabling the ADC first cause in TivaWare workshop (lab6) they leave

ADCs speed to default 1MSPS :)

To me its absolutely logical to first configuring the clock speed

Thats what you also would do in hardware to prevent spikes

on the clock line.

Anyway, doing that it will work fine also as a ROM_ call to the API.

Have fun

Peter

Hello again,
Well, that's what I'm worried about: a headache in the future. I fully agree with you when you say there is no justifying logic, but the point is: with StellarisWare it seems to work fine, but with the replacing TivaWare, supposed to be compatible with Stellaris, the program fails, locking up in a ISR.
This is the first time I'm using TI microcontrollers and I'm also a beginner in this Forum, which I found, by the way, very productive with the assistance I received. Probably you are an experienced frequent user, I guess. So let me ask you one question: don’t TI people help with this kind of Issues, and if they do, how can we get their support?
One more question, may I know your name?
Have a nice weekend,
Tks,
Zander

Peter Krengel said:

To me its absolutely logical to first configuring the clock speed

Might that "absolute logic" continue then to the calling of each/every peripheral function - prior to the (necessary) earlier call to, "SysCtlPeripheralEnable()?"

And if not - why not?   Suspect your absolute logic may need bit more (i.e. some) basis - or be less absolute...

Hi Peter,

Putting that way, It makes sense, but TI is explicit in their Stellaris Workbook (pag. 59):

"Before calling any peripheral specific driverLib function, we must enable the clock for that peripheral. If you fail to do this, it will result in a Fault ISR (address fault). This is a common mistake for new Stellaris users."

As you see, thats my case: new user!

But what I still don't understand is why TI does not manifest anything!  If it is different with TIVA C, shouldn't they be explicit as well? At least for us, the beginners...

Have fun you to,

Zander

Guys - do understand - this switch to "rebrand" is vast - "growing pains" very likely to result.

Being "early adopter" too often yields such results.  (thus our group avoids - till early (pioneer) bodies removed from trail)

"Trick" in play here (violate the practice you list - even though its "absolute") cannot be counted upon - the SW migration is substantial effort - and vendor SW team is skilled - improvements (corrections/fixes) likely to emerge.  (and then our group may consider such use...)

Suggest that best - longest lasting "fun" - unlikely to result from, "magic."  (especially indefensible - and absolute...)

Zander,

I'm not a experienced user with TI processors rather than

other branches. I do programming since 30 years

but in assembler rather than C or other higher languages.

I started using TI devices because of the good support

TI gives normaly. But now after changing parts numbers

etc. there seems to be a little bit mess in. Lets wait until

all bugs have been removed. Until that I guess we have

to do some experiments using the devices and the software.

You can see my name above.

@cb1_mobile:

Why are you so aggressive?

Maybe that switching on the device first is logical to you.

For me as a mainly hardware man it is not and I also will

tell you why it isnt: If you want to connect any hardware device

which has to be clocked, you first will physically connect

the clock line. After that you will enable the device, wont you?

If you do that vice versa you will get spikes on the clock line.

Right?

Ok I know thats only a theory to use that on software too ;)

But in hardware this would be correct.

My idea is, that our problem we are discussing is a

problem of the debugger in CCS rather than a real

hard- or software problem.

Lets wait what TI will have to say to that.

Until then we can first set the speed and then

enable the device :)

Regards

Peter

Peter Krengel said:

Why are you so aggressive?

Cannot agree with your unkind description. 

Instead - case can well be made that I reacted to advice which is totally outside/contrary to that long published/listed here.  (and presented by original poster!) 

Should I remain silent - and have others, "fall victim?"  The "absoluteness" of your belief - minus any justification (especially logic) greatly concerns.

While there may exist some HW "carryover" - when such "hunch" is in clear/total disregard of long published SW dictates - is it not, "normal/customary" to react?  And - despite your "absolute logic" - that is far from aggressive...  Appropriate seems far better fit... 

@cb1_mobile:

Another idea why it works like I tried out:

SysCtlADCSetClock is a API which sets the Clock Modules configuration rather then the ADC

configuration.

So it seems to be logical that I cannot connect the ADC to the

clocking device and after that changing the setting of the

clocking module without disconnecting the ADC first.

Enabling any peripheral will not switch on its power

Enabling a device switches on the its clocking.

Anyway...it works and vice versa it doesnt.

For me I now will stop the discussion cause going on wont

make any sense.

Peter

cb1_mobile,

If I understood you well and considering that TI says that Stellaris (Cortex M4) is being replaced by Tiva C and Stellaris, soon, no longer will be supplied, the best to do is to pick some other stable chip, may be from other family or brand.
Is that correct?
Tks,

Zander

Peter Krengel said:

SysCtlADCSetClock is a API which sets the Clock Modules configuration rather then the ADC

Now you are onto something!   Very good.

I don't fully subscribe to all of your most recent post - but that quoted - well done...

The apparent "blend" of functions - when it is not immediately clear which peripheral (or peripherals) are impacted - may have surfaced.

Again - we have beyond 10K boards in the field (not that MCU - but other Stellaris) and have always enabled the peripheral prior to any other call to that peripheral...  And such was repeatedly - and loudly - drummed into us by vendor staff...

@ Zander - My statement was that it is "normal" to expect some uncertainty when new devices and/or vast SW is introduced - by any vendor.  Nothing else was suggested nor implied.

My time/efforts here - dating to forum's LMI inception - confirm my belief in vendor's products/capabilities. (yet not always, "methods")

You said something crystal clear: " there seems to be a little bit mess in".
I tried to use some links from Stettaris docs and they were addressed to TIVA C.
But I also understand the tough job TI engineers are probably facing with this rebrand.
Anyway Peter, thanks again for all your comments, always very didactic

Zander

PS: Sorry, I did not mean to know your name as I knew already. Actually I was asking @cb1_mobile and, by mistake, addressed to you.

to Zander and cb1_mobile:

I agree, have a great weekend and much fun.

Cu again at the next discussion.

Peter

No comment from TI ! It seems there was disagreement in this thread

that was never resolved. Here is some more data:

// Using Tiva Launchpad TM4C123GXL, and udma:

// case 1: fail
// fault interrupt occurs on a subsequent BX R14 with a valid return address
// but note the adc hardware does have a clock before the enable
SysCtlClockSet(
   SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
   SYSCTL_XTAL_16MHZ);
SysCtlADCSpeedSet(SYSCTL_ADCSPEED_1MSPS);
SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS); // or any speed

// case 2: okish
// no SpeedSet: works at 125KSPS - is this the default clock to the ADC ?
// but the first samples are unclean
SysCtlClockSet(
   SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
   SYSCTL_XTAL_16MHZ);
SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

// case 3: okish
// works at specified speed
// but the first samples are unclean
SysCtlClockSet(
   SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
   SYSCTL_XTAL_16MHZ);
SysCtlADCSpeedSet(SYSCTL_ADCSPEED_250KSPS);
SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

// case 4: fail
// works at 1MSPS, not at specified speed
SysCtlClockSet(
   SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
   SYSCTL_XTAL_16MHZ);
SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS);
SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOE);
SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

// case 5: ok
// works at specified speed
// and the first samples are clean
SysCtlClockSet(
   SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
   SYSCTL_XTAL_16MHZ);
SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOE); // also sets adc speed to 1MSPS
SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS); // set required adc speed
SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0); // enable adc

This last case looks good, but there are many untried alternatives. Just because something is working in the field doesn't mean it will work when you use the next silicon revision. We need to know best practice.

TI, are you there ? 

Richard Theobald said:

TI, are you there ? 

Believe Ms. Cozart's answering, sticky post (6th from top, here - Oct 1, '13) answers in the affirmative.  (Unclear if you saw that - doubt much more reveals - your report does make the appeal...)

http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/293858.aspx

Speaking of "best practice"... "okish" (clean/unclean) may have escaped such classification...

oops, bad cut and paste, I should have written

SysCtlPeripheralReset(SYSCTL_PERIPH_ADC0); // also sets adc speed to 1MSPS

not

SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOE); // also sets adc speed to 1MSPS

>Believe Ms. Cozart's answering, sticky post (6th from top, here - Oct 1, '13) answers in the affirmative.  (Unclear if >you saw that - doubt much more reveals - your report does make the appeal...)

Thanks, I hadn't see that, and apologies for my colloquial offence.

Apologies not at all required - but I sense you to be skilled/experienced - could not resist.

Our group has resisted migration to that rebrand effort - have multiple, past "teaching moments" (warning against over-eager adoption of the complex) and prefer the mantra, "If you like your StellarisWare (tested/long proven) you may keep your StellarisWare."  Pioneers often recognized by arrows protruding (especially from soft tissue) - that won't soon be me...