Wrong value read from internal temperature sensor on LM4F232H5QD B0

Suspect that 2 items will aid factory folk in response:

a) Do all other uses of ADC work/perform as expected?

b) Is this a single board anomaly? - Far better report if this repeats across several boards/chips

Our group has noted that many such issues reduce (or resolve) w/lowered System Clocks and slowest ADC conversion speeds.  Suggest that you repeat test w/SysClk @ 50MHz and conversion speed dialed to lowest (125KSPS - iirc).

Wise also to double check that each/every VDD and GND pin actually are soldered - even a single pin "miss" may wreak havoc...

And - your newer ver MCU may (probably does) require an updated MCU "part define" (i.e.  "TARGET_IS_BLIZZARD_RA2" may have to change to  "TARGET_IS_BLIZZARD_RB0") (I'm guessing here!)  w/in your code and/or IDE.

After some tests here are my findings:

a) All our other ADCs are working as expected. In fact we are using an external temp sensor which is always reading a hotter (and correct) temp than the external temp.

b) This happens on both of our custom boards we have at this time

I have not tested with reduced clocks yet, but plan to later today.

Pins all look good and soldered on both boards.

I wasn't aware that these defines could change based on processor revision number, but it doesn't seem that there is a *_RB0 used anywhere in StellarisWare at this time. It also seems that these are only used in driverlib/rom.h which we are currently not utilizing.

Another update ... slowing the ADC sample speed down to 125KSPS didn't help either. Still getting the same results.

Oh well - appreciate both your effort & feedback - I do suspect that these tests will be of use to vendor - when they arrive this scene...

Like you - I have older model M4 on that Eval board.  Thus no means for our test/confirm...

We do use 64 pin LX4F - and note 3 separate power supply pin designators: VDD, VDDA and VDDC.  We feed VDDA thru a mini ferrite bead - close to the MCU w/bypass cap attached.  VDDC Cap value is tightly spec'ed - are you in compliance?

If you're running Sys Clock at/near suggested 50MHz - and have not disabled most peripherals - and are not primarily in "Sleep/Deep Sleep" - I cannot account for your abnormally low, internal Temp reading...

We also run VDDA through a ferrite bead with bypass caps and have the caps on VDDC exactly as stated in the specification.

It seems I may need some help from someone at TI which as the latest B0 processors running somewhere so they can make the same tests. 

Thanks for the help in troubleshooting!

Agreed - we've at minimum covered the "basics" - saved factory that "back/forth." 

Final point - in a "serious" system it is often unwise (even disallowed) to ask a component to "pass judgement" upon itself.  Thus a secondary temp sensor may well deserve a place w/in your design - especially as the performance status of the internal device raises question...

We also agree with your point of needing a secondary temp sensor. We are utilizing the same temp sensor as is on the LM4F232 eval board to have an external temp as well. But we would also like to be able to see the temp difference between CPU and external temp (especially when running our product through temp testing). If we can't get a good reading at room temp then we cannot trust it at high/low temps. :-)

Plus we are hoping this isn't a symptom of a different problem which just hasn't exhibited itself yet.

Hi,

has there been any further answers to this?

I have a similar problem, when using the internal temp sensor. But with mine the temperature is too high (meaning the adc-value is too low).

ADC Value around 1883 at 25.5°C (-> leads to display of ~36°C) . Using the formula from the datasheet it should be around 2019. Other ADC Values are ok.I am using an A3 type lm4f230h5qr.

This just to keep the thread alive and be notified if there is any solution on this.

Greetings,

 Jan

Jan,

Unfortunately I have not received any further help than what you have seen here in this thread ... am hoping that someone from TI can shed some light on this.

Kyle

Kyle and Jan,

The only issues we've seen are where is errata is not followed correctly.  It's important that 3 conversions from the temperature sensor are taken consecutively.  If the ADC input multiplexer selects any other channel, then the voltage from that channel will influence the temperature measurement.  If the voltage is higher than the internal sensor, the raw temperature value will be higher and the converted temperature will read low - and vice versa.  From this thread, it looks like you've accomodated this errata correctly, but please confirm this.

cb1_mobile said:

And - your newer ver MCU may (probably does) require an updated MCU "part define" (i.e.  "TARGET_IS_BLIZZARD_RA2" may have to change to  "TARGET_IS_BLIZZARD_RB0") (I'm guessing here!)  w/in your code and/or IDE.

Jonathan,

Would you be so good as to address issue flagged, above?  (requires "insider knowledge")  Thanks...

Jonathan,

Yes, I am working with the workaround for the errata for the internal temp sensor. In fact I have uploaded the code (slightly modified version of SW which was given to me by another employee of TI) which I am using to test this here: http://pastebin.com/KZfNG4X8

As stated above, this code works perfectly on my eval board for the LM3F232 (rev A3 of processor), but doesn't work as expected when loaded on our custom hardware (rev B0 of processor). I have looked into what cb1 stated about the #define for the processor rev, but currently we have TARGET_IS_BLIZZARD_RA1 defined in the project, but there is nothing in our version of TI-RTOS (v1.1.0.25) which is triggered off of a different revision (ie. there is no reference to TARGET_IS_BLIZZARD_RA3 or TARGET_IS_BLIZZARD_RB0). Plus this is only used within the rom.h file which we don't utilize at all at this point in time.

Thanks,

Kyle Cottongim

Kyle,

I don't see any changes between MCU revisions that would explain what you're seeing.  We did not change anything in the temperature measurement circuit.  As you mentioned earlier, the target definition is most applicable to ROM calls.

Any there any notable hardware differences between the EKB and your design? For example, what are you using for an external voltage reference? 

Perhaps factory - in seeming possession of multiple such devices - could perform test/verify w/versions reported by both requesters... 

Fact that 2 independent users report similarly - may justify such effort.  (to be sure - and possibly "sound alarm/correct" should their report prove correct...)

We're going to look at our validation data for the internal temperature sensor to see if there are any clues on the issues being reported.  I'll provide an update shortly.

Jonathan,

Our peripheral set is different than that of the EK-LM4F232 eval board, but most everything else is the same. We have the same main and hibernation oscillators and the VREFA+/- inputs are the same as on the eval board. We use +3V for VREFA+ and GND for VREFA- with a 0.01uF and 0.1 uF cap across these inputs just as in the eval board's schematic.

VDDA and GNDA are connect the same as on the eval board with the exception of the 3.3V input being passed through a mini ferrite bead. And the VDDC inputs have the exact same cap values as the eval board.

Thanks,

Kyle Cottongim

Kyle and Jan,

We have some preliminary data that appears to match what you're seeing.  This is now being compared to earlier data sets. I'll post again when we have more information.

Another update: After checking the test code for the data set from yesterday, someone realized that the first 2 samples were not being properly discarded (per the erratum).  With the software changed the temperature readings are within +/- 2degC using a temperature-controlled environment.  So my last post was a false alarm.

Can you post snippets of your ADC code?  Perhaps there's some code that causes the ADC to select another input.  Anytime another channel is converted, 2 consecutive temperature sensor conversion must be discarded before the temperature conversion is accurate.

In a previous post in this thread I put a link to the code I am using to do this testing. 

to those interested:

Kyle's code reveals the admittance of a "foreign" (i.e. not TS) read w/in the step sequence - thus a seeming violation of Jonathan's guideline:

"If the ADC input multiplexer selects any other channel, then the voltage from that channel will influence the temperature measurement." 

Do note - this reporter has many months past - repeatedly reported the observance of ADC "cross-talk" upon both LM3S and LX4F devices.  The greater the "Voltage Delta" between consecutive steps - the greater the impact!  Even the buffering provided by 2 "empty" step conversion reads - may not have prevented this...

    ADCSequenceStepConfigure(ADC0_BASE, ADC_SEQUENCE_NUM, 0, CHAN_EXTTEMP);
    ADCSequenceStepConfigure(ADC0_BASE, ADC_SEQUENCE_NUM, 1, ADC_CTL_TS);
    ADCSequenceStepConfigure(ADC0_BASE, ADC_SEQUENCE_NUM, 2, ADC_CTL_TS);
    ADCSequenceStepConfigure(ADC0_BASE, ADC_SEQUENCE_NUM, 3, ADC_CTL_TS | ADC_CTL_IE | ADC_CTL_END);

Not too hard to excise, "CHAN_EXTTEMP" - and re-run such test.  Again - our group's testing has revealed likelihood of "cross-talk" across channels...

May be beneficial for "Jan" to likewise - "test & report."

Pity that a 4 channel - completely confined to TS - conversion is mandated!  (Sequence 3 - single conversion - "ideal for such purpose" - thus discarded - "out in the cold!")

Hi,

seems this thread got quite busy last week. Only got back in the office today, so here's my current test report:

About the 2 discarded samples: If I used software oversampling 2 or 4 times, would i still need 3 samples? Shouldn't discarding the first sample be enough then? 

Still, even with this configuration below the temperature is still shown at 25.7°C while board and outside is 22°C. (Runtime was at this point just about 10s so internal temperature rise seems unlikely in this magnitude).

ADC Values were 0x164, 0x76C, 0x7DB, 0x7DF with the first being another channel and the last three internal temp sensor.

Anyway, this is the current code I use for the temperature sensors.

In the Init File:

 ADCHardwareOversampleConfigure(ADC0_BASE, 0); //! no Hardware Oversampling for ADC0

 ADCSoftwareOversampleConfigure(ADC0_BASE, 3, 0); //! 0 Times Softwareoversampling for ADC0 Sequence 3

 ADCSequenceConfigure(ADC0_BASE, 3, ADC_TRIGGER_PROCESSOR, 0); //!Trigger ADC0 Sequence 3 via function call

In the Interrupt:

 ADCSequenceStepConfigure(ADC0_BASE, 2, 0, ADC_CTL_CH6); //!< ADC0, sequence 2, step 0, interrupt, channel 6/pd1
 ADCSequenceStepConfigure(ADC0_BASE, 2, 1, ADC_CTL_TS); //!< ADC0, sequence 2, step 1, interrupt,internal temp sensor
 ADCSequenceStepConfigure(ADC0_BASE, 2, 2, ADC_CTL_TS); //!< ADC0, sequence 2, step 2, interrupt,internal temp sensor (for stabilizing voltage -> see errata)
 ADCSequenceStepConfigure(ADC0_BASE, 2, 3,
   ADC_CTL_IE | ADC_CTL_END | ADC_CTL_TS); //!<  ADC0, sequence 2, step3, interrupt,internal temp sensor

I also tried changing the first step also to TS so the whole sequence is only for internal temp-sensor. The result was: 0x788,0x7BC,0x7BC,0x7C7

This lead to a temperature of about 27,1°C while outside still about 22°C, but after a few minutes of on-time so internal heating might be an issue (not noticeable from outside).

Greetings,

 Jan

Jan's results seem to confirm the need to:

a) employ one of the 4 step sequences when attempting internal Temp Sense

b) restrict every one of those steps to Temp Sense measurement

c) first two "steps" in required Sequence 0, 1, or 2 are to be discarded - are not "corrected" via any "over-sampling."

Portions of your latest code show Sequence 3 - which while "natural, desirable & efficient" appear outside the bounds of required, back to back measurements & discard.  (instead Sequence 1 or 2 should be selected)

From past experience - multiple other ARM MCUs and others - expecting a "precise" temperature measurement may be unrealistic.  Suspect that a "baseline" can be gleaned - and then deviations from this may prove of greater value...

cb1,

Thanks for your review of Kyle's code, although my read of it suggests everything is OK as far as meeting the requirements of the errata.  Sample Sequencer 0 is an eight-step sequencer, configured for 4 steps, which seems OK to me. 

Kyle,

Have you tried printing the Raw ADC values to see if they are as expected?  In looking at your code, the only thing that concerns me is the scaling math - specifically assumptions about how the compiler handles the type conversions from integer to float.  I wonder if the MVDIV macro is being treated as an integer operation.  Suggest adding type casting and appending 'F' to any numeric constants force compiler to recognize them as floating-point values.

@Jonathan,

All here appreciate/value your interest/contributions - thank you.

That said - our group continues to believe & follow your earlier recommendation: "If the ADC input multiplexer selects any other channel, then the voltage from that channel will influence the temperature measurement." 

And - along w/the potential conversion issues - we strongly suspect the "intermix" of non TS may "impact" TS readings.  (especially so when the "raw" ADC level from non-TS step differs substantially from TS)  We've confirmed this on multiple, different Stellaris M4s - across multiple boards - and in each/every case - isolating TS improves results...

And - as 4 channel sequence is "demanded" by current errata-level - (1st 2 conversions discarded) what really is the point of "jeopardizing" the desired TS reading so that one more, non TS, ADC reading (itself potentially contaminated by TS) may be had?   Bit pointless - mais non?