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.

TIVA ADC Problem reading die temperature (TM4C123GH6PM)

Other Parts Discussed in Thread: TM4C123GH6PM, LM3S1627

I have a bare-metal application where I am getting a strange set of die temperature readings.  They are strange in that they are 7 or 8 C below the ambient air temperature (and thus, at least 15C below the expected die temp).  I've looked at all of the possible culprits I can think of and have had no success in determining why the calculated values are so far off.

I am sampling an analog input (PE3) and the die temperature in the same sequencer (SS2).  I have trimmed the software calculations (manually) to include the measured Vdda value and the analog voltage calculation is in very good agreement with the measured voltage at PE3.  With this result, I would expect all external issues (variations in Vdda, power supply noise, etc...) to be common to the two measurements.

I have read the errata (ADC#09 from "SPMZ849D–August 2013–Revised August 2014") for the GH6PM and have tried placing the temp sensor in all 4 SS slots with no change in the result.  In fact, this part does not seem to express the errata because the first FIFO reading is usually within 1 LSB of the last.  I also have hardware averaging turned on (64 samples), but this does not affect the issue, it just smooths out the readings.  With no HW averaging, the raw ADC values vary by something like +/-20 LSBs (not nearly enough to account for the observed offset).

The part being used was salvaged from a TM4C1294 launchpad (it was the JTAG interface processor).  Is it possible that the parts used for the launchpads to have relaxed acceptance specifications on the peripheral modules that are not needed for the JTAG application?  I am not confident in this possibility since a TM4C123GH6PM launchpad that I have gives even lower readings for Tj (see below).

I am confident that the sensor is being accessed since I can blast the MCU with cold spray and get a significant drop in calculated temperature followed by a slow return to the original value.

Below are code snippets in case they are of assistance.  As pictured, SS2 is configured to gather 4 temperature readings.  The commented line above that is what I use to gather the AIN0 and TS readings.  As mentioned above, when this line is included (and the next commented out) the AIN0 readings appear correct.  This is output from the SW showing the captured ADC readings and calculated values (shown for the all-TS SS configuration):

#samps: 4, R0: 2163, R3: 2162
eng: V0: 1.74 V, Tj: 17.26 C
stats: s0: 1000, s3: 0003

These are some readings from the GH6PM launchpad (un-modified) -- Vdda is within 0.01V of the application MCU:

#samps: 4, R0: 2269, R3: 2270
eng: V0: 1.82 V, Tj: 10.75 C
stats: s0: 1000, s3: 0003

Note: The status words are captured before the ADC values are read from the FIFO, so that is why the last status indicates that the FIFO is not empty.

Ambient air temp for both targets was 26C, and this was in a controlled environment with both die sets fully acclimated to the ambient temp (in other words, I didn't just drag either board in from arctic storage and start testing them).

ADC INIT (not shown is the GPIO init which happens elsewhere.  Since ANIN0 is working as expected, I don't consider it relevant here):

U16 adc_init(void)
{
	volatile uint32_t	ui32Loop;

    // ADC init
	SYSCTL_RCGCADC_R |= SYSCTL_RCGCADC_R0;			// enable ADC clock
	ui32Loop = SYSCTL_RCGCADC_R;
	SYSCTL_RCGC0_R |= SYSCTL_RCGC0_ADC0;   			// activate ADC0 (legacy code)
	ui32Loop = SYSCTL_RCGC0_R;

	GPIO_PORTE_AFSEL_R |= SPARE5;					// enable alt fn, PE3
	GPIO_PORTE_AMSEL_R |= (SPARE5);
	ADC0_CC_R = ADC_CC_CS_PIOSC;					// use PIOSC
	ADC0_PC_R = ADC_PC_SR_125K;						// 125KHz samp rate
	// ADC sequencer init
	ADC0_SSPRI_R = 0x1023;							// Sequencer 2 is highest priority
	ADC0_ACTSS_R &= ~ADC_ACTSS_ASEN2;				// disable sample sequencer 2
	ADC0_EMUX_R &= ~ADC_EMUX_EM2_M;					// seq2 is software trigger
	ADC0_SSMUX2_R = 0x0000;							// set channels, PE3 = ain0
//	ADC0_SSCTL2_R = (ADC_SSCTL0_TS1|ADC_SSCTL0_IE1|ADC_SSCTL0_END1);
//													// TS0 is 2nd sample, IE0 enabled after 2nd samp
	ADC0_SSCTL2_R = (ADC_SSCTL0_TS3|ADC_SSCTL0_TS2|ADC_SSCTL0_TS1|ADC_SSCTL0_TS0|ADC_SSCTL0_IE3|ADC_SSCTL0_END3);
													// do 3 samples of Tj per eratta ADC#09
													// TS is 4th sample, IE enabled after 4th samp
													// ignore 1st 2 TS samples, only use TS3 reading
	ADC0_SAC_R = ADC_SAC_AVG_64X;					// set 64x HW averaging
	ADC0_IM_R &= ~ADC_IM_MASK2;						// disable SS2 interrupts
	ADC0_ACTSS_R |= ADC_ACTSS_ASEN2;				// enable sample sequencer 2
	return 0;
}

This function reads the fifo into an array (data and status are captured as sequential words in the array):

U8 adc_in(U16* p)
{
#define NUM_SAMPS	4		// number of samples in sequence
	U8	i;

	ADC0_PSSI_R = ADC_PSSI_SS2;						// initiate SS2
	while((ADC0_RIS_R & ADC_RIS_INR2) == 0);		// wait for conversion done
	for(i=0; i<NUM_SAMPS; i++){
		*p++ = ADC0_SSFSTAT2_R & 0xffff;			// get fifo status in 1st buffer word
		*p++ = ADC0_SSFIFO2_R & 0x0fff;				// read result in 2nd buffer word
	}
	ADC0_ISC_R = ADC_ISC_IN2;						// acknowledge completion (clr flag)
	return i;
}

Finally, this is where I calculate the voltage/temperature for display (3.29V is what is measured at pin 2 of the MCU) (adc_in() is called prior to this snippet):
	//	TJ = 147.5 - (75 * (rawADC * 3.29 / 4096))
	fa = 147.5 - ((float)adc_buf[7] * 60.242E-3);           // fa is the die temp from sample 4
	fb = (float)adc_buf[1] * 803.223E-6;                         // fb is the voltage for sample 0
	sprintf(obuf,"eng:  V0: %.2f V, Tj: %.2f C",fb,fa);
	puts0(obuf);

Thanks for taking a look.

  • Hello Joseph

    Very well written post. Rarely do we get a post which has a clean-start, expressive middle and crisp-end. I would be able to get back to you on Monday (earliest) as I would need to test it out.

    Also please note that I would be using TivaWare API's as the DRM method that you have used is something I avoid.
  • It seems a waste of time to send vague questions and hope for earth-shattering responses.

    I've been contemplating using the TI RTOS for a while, but now have a code base in place, so there is a significant work-function involved to tunnel out of this well. No worries on using the TI APIs.

    I appreciate your time and look forward to any assistance you may be able to offer.

    Cheers,

    Joe
  • TI RTOS and Tivaware are independent, I'm using Tivaware with a bespoke run to completion executive. That is pretty close to a bare metal application. There's considerable benefit to using the Tivaware library in that case.

    Robert
  • Log this as, "Applause #2" for a well constructed post.   (but for the time-drain forced upon "helpers" by (dreaded) DRM)

    May I offer these suggestions:

    • Have you a 2nd board (perhaps not as you've "acquired" your MCU from another board)?    Second board mitigates against, "Single board anomaly."
    • Substantially change the signal level injected into that ADC input & see if signal "bleed" impacts.
    • Poster Robert always advises the addition of small ceramic cap very close to MCU's ADC pin.
    • Are all power pins properly routed - and contain proper number/value bypass caps?

    It is not (always) that "earth shattering" responses (are) required - those ruled, "Good for Gov't Work" often prove acceptable...

  • As noted in the original post, I have both my project board (a layout of my creation) and a TM4C123GH6PM launchpad.  Results from both of these boards are present in the original post and the launchpad produces a lower Tj result than my board.

    While I made an effort to make the post complete, there are always details that seem to pass under the radar.  I am pretty OCD about bypass caps.  They must go as close to the component as possible and vias are on the far side (away from the component).  This implies, but I explicitly now state, that the cap must be on the same side of the board as the component.  For "good chips", Vss and Vdd are adjacent to each other, making the task of attaching the bypass cap easy.  This part is in that class, so all of the bypass caps are within about 100 mils of a Vdd/Vss pin pair.

    More details.  I TOTALLY goofed the core supply on this layout (it was a rush job ancillary to the main subject of the panel.  The excuse I will stick to for eternity, at least).  So, the bypass for the core is unconventional.  The caps for the core (two 0.1uF and one 2.2uF) are on the top of the MCU package, and are strung between a pair of wire-wrap wires - one routes between the two Vddc pins, and the other two route between adjacent (or nearly so) GND pins.  As far as recoveries go, it looks excellent, but could potentially influence the die in ways that would be difficult to predict with stone knives and bearskins (what I generally have to work with vis-a-vis EMC modelling SW).  The PCB is 2-layer, but the bottom is substantially ground with limited breaks.  Vdd traces are at least 20 mils for most of the route from the 3.3V regulator.

    Lastly, the Vdd lines feeding the MCU have a 2 ohm resistor in series.  One for Vdd and another for Vdda.  For Vdd: on the MCU side of this resistor are four 0.1uF caps and a 2.2uF cap.  For Vdda: there is just a single 0.1uF cap.  I temporarily placed a 2.2uF cap across Vdda with no change at all in the result.  What I haven't tried is shorting the 2 ohm resistor...  Having now just done this, I can report that it makes no difference.

    All caps are 0402.  I do not have any V/C data for them at the moment, but the 0.1uF caps are rated at 50V, the 2.2uF ones are 16V.  So, the backroom suggests that these should be reasonable caps at or below 3.3V.

    So, given the above (with apologies for length), It does not appear to me that the MCU power supply is a primary culprit.  Rose colored glasses notwithstanding.

    That leaves the injection proposal as the only thing on your list that I have not tried.  Given that I am running sequencer 2 with all 4 slots assigned to the temperature sensor, I would expect cross-channel bias issues would be the he fifth horse of the apocalypse.  Still, it is a worthy data point, but will have to wait until tomorrow for me to set-up and execute.

  • Quite a neat reply - proves your initial writing (to applause) was no fluke.

    Now you wrote that you (expected) the MCU's reported die temperature to be w/in 7-8°C of ambient. May I ask how you've come to that conclusion?

    Firm/I have noted that multiple variables along w/power supply; pcb layout (routing & copper weight); MCU Speed; and MCU's task demands - all impact die temp. - and (often) exceed the 7-8°C mentioned. (unmentioned - yet of interest - is whether your "die temp" reading resulted from a single measure or via a looping series of readings...)

    In addition - unnoted is, "How soon after power up" you attempt to read, "T_die!"    Having past worked for semi giant - their (similar) MCU junctions required (some) time to reach operating temperature.    Perhaps a "too early" read (post power up) explains your observation...

    For completeness - although (still) "Fifth Horse" - is it possible that MCU board was stored in a cooler environment - then moved to a warmer location - and then quickly, powered and probed?   (Oft the case w/our "controlled storage environment" clients...)

  • cb1 said:
    Now you wrote that you (expected) the MCU's reported die temperature to be w/in 7-8°C of ambient. May I ask how you've come to that conclusion?

    That's a good question. Early in design I looked at using the MCU temperature sensor and came to the conclusion it was too ill-characterized. I could find no information on how closely coupled it was to either the ambient or the core temperature of the die. So I simply added an external temperature sensor. The die itself appears to have small enough self-heating that monitoring it isn't particularly useful.

    As far as the sensor itself the accuracy stated is +/-5C plus A/D error on my copy of the data sheet. 7 or 8C below ambient would appear to be within spec if on the extreme side.

    Robert

  • T-Ambient is measured with a credible probe at 26C.  Tj readings start around 19C at power-up (this means within a few seconds to as long as a minute after applying power), thus if one assumes a slow die-temp ramp, one would expect the starting temp to AT LEAST be what the room temp sees.  Thus, the statement in the original post that "Tj is reading AT LEAST 7-8C below Ta".  Tj will creep up to as much as 22C after 20 minutes.

    These boards (both the custom layout and the LaunchPad) are all sitting on the bench in my office, where they have been for several days.  I have experienced the temperature variations that one can see when a typical HVAC system cycles on/off (those with a masochistic bent may view http://www.rollanet.org/~joeh/projects/GPSDO_writeup.pdf).  I have not yet gone to the extreme of logging temperature over something like an hour to see if there is a quantifiable variation.  Another worthy experiment that I will try this evening.

    My expectation of a Tj reading that is something more like 30-40C is anecdotal based on similar MCU form-factors operating in the same power ball-park (0.25-ish W).  As an example, I have an SiLabs C8051F120-based board with similar layout techniques that is reading Tj of something like 35-40C on the same bench at the same time.

    The +/-5C spec is known to me, and I am happy with that value, but the observed behavior is still difficult to swallow even assuming a corner condition.  For example, I have readings from the LaunchPad that show 10C for Tj.  That is *16 C* below Ta.  That doesn't seem very "in-spec" even for an outlier.

    The API I am using has a UART-based command-line that allows me to execute debug commands.  One of these is to constantly loop out ADC readings (one-line examples of these outputs are in the original post).  The readings are paced at 100ms intervals.

    As to the characterization question, I hate to throw rocks, but this is something on my radar.  There doesn't seem to be any change in the documentation since the processor was Stellaris (when Luminary held the design).  This is something like 8 years old (more or less), making it likely that there have been at least one or two process changes since the original design was released.  Just spitballs, but it is a worthy question at least.

  • Hello Joe

    I ran my test code on 2 different TM4C123x devices and I get the same result of 23-24C under a thermostream set at 25C. Attached is the CCS main project file.

    //*****************************************************************************
    //
    // temperature_sensor.c - Example demonstrating the internal ADC temperature
    //                        sensor.
    //
    // Copyright (c) 2010-2016 Texas Instruments Incorporated.  All rights reserved.
    // Software License Agreement
    //
    //   Redistribution and use in source and binary forms, with or without
    //   modification, are permitted provided that the following conditions
    //   are met:
    //
    //   Redistributions of source code must retain the above copyright
    //   notice, this list of conditions and the following disclaimer.
    //
    //   Redistributions in binary form must reproduce the above copyright
    //   notice, this list of conditions and the following disclaimer in the
    //   documentation and/or other materials provided with the
    //   distribution.
    //
    //   Neither the name of Texas Instruments Incorporated nor the names of
    //   its contributors may be used to endorse or promote products derived
    //   from this software without specific prior written permission.
    //
    // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
    // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
    // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
    // A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
    // OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
    // SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
    // LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
    // DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
    // THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
    // (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
    // OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    //
    // This is part of revision 2.1.3.156 of the Tiva Firmware Development Package.
    //
    //*****************************************************************************
    
    #include <stdbool.h>
    #include <stdint.h>
    #include "inc/hw_memmap.h"
    #include "driverlib/adc.h"
    #include "driverlib/gpio.h"
    #include "driverlib/pin_map.h"
    #include "driverlib/sysctl.h"
    #include "driverlib/uart.h"
    #include "utils/uartstdio.h"
    
    //*****************************************************************************
    //
    //! \addtogroup adc_examples_list
    //! <h1>ADC Temperature Sensor (temperature_sensor)</h1>
    //!
    //! This example shows how to setup ADC0 to read the internal temperature
    //! sensor.
    //!
    //! NOTE: The internal temperature sensor is not calibrated.  This example
    //! just takes the raw temperature sensor sample and converts it using the
    //! equation found in the LM3S9B96 datasheet.
    //!
    //! This example uses the following peripherals and I/O signals.  You must
    //! review these and change as needed for your own board:
    //! - ADC0 peripheral
    //!
    //! The following UART signals are configured only for displaying console
    //! messages for this example.  These are not required for operation of the
    //! ADC.
    //! - UART0 peripheral
    //! - GPIO Port A peripheral (for UART0 pins)
    //! - UART0RX - PA0
    //! - UART0TX - PA1
    //!
    //! This example uses the following interrupt handlers.  To use this example
    //! in your own application you must add these interrupt handlers to your
    //! vector table.
    //! - None.
    //
    //*****************************************************************************
    
    //*****************************************************************************
    //
    // This function sets up UART0 to be used for a console to display information
    // as the example is running.
    //
    //*****************************************************************************
    void
    InitConsole(void)
    {
        //
        // Enable GPIO port A which is used for UART0 pins.
        // TODO: change this to whichever GPIO port you are using.
        //
        SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    
        //
        // Configure the pin muxing for UART0 functions on port A0 and A1.
        // This step is not necessary if your part does not support pin muxing.
        // TODO: change this to select the port/pin you are using.
        //
        GPIOPinConfigure(GPIO_PA0_U0RX);
        GPIOPinConfigure(GPIO_PA1_U0TX);
    
        //
        // Enable UART0 so that we can configure the clock.
        //
        SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    
        //
        // Use the internal 16MHz oscillator as the UART clock source.
        //
        UARTClockSourceSet(UART0_BASE, UART_CLOCK_PIOSC);
    
        //
        // Select the alternate (UART) function for these pins.
        // TODO: change this to select the port/pin you are using.
        //
        GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    
        //
        // Initialize the UART for console I/O.
        //
        UARTStdioConfig(0, 115200, 16000000);
    }
    
    //*****************************************************************************
    //
    // Configure ADC0 for the temperature sensor input with a single sample.  Once
    // the sample is done, an interrupt flag will be set, and the data will be
    // read then displayed on the console via UART0.
    //
    //*****************************************************************************
    int
    main(void)
    {
    #if defined(TARGET_IS_TM4C129_RA0) ||                                         \
        defined(TARGET_IS_TM4C129_RA1) ||                                         \
        defined(TARGET_IS_TM4C129_RA2)
        uint32_t ui32SysClock;
    #endif
    
        //
        // This array is used for storing the data read from the ADC FIFO. It
        // must be as large as the FIFO for the sequencer in use.  This example
        // uses sequence 3 which has a FIFO depth of 1.  If another sequence
        // was used with a deeper FIFO, then the array size must be changed.
        //
        uint32_t pui32ADC0Value[1];
    
        //
        // These variables are used to store the temperature conversions for
        // Celsius and Fahrenheit.
        //
        uint32_t ui32TempValueC;
        uint32_t ui32TempValueF;
    
        //
        // Set the clocking to run at 20 MHz (200 MHz / 10) using the PLL.  When
        // using the ADC, you must either use the PLL or supply a 16 MHz clock
        // source.
        // TODO: The SYSCTL_XTAL_ value must be changed to match the value of the
        // crystal on your board.
        //
    #if defined(TARGET_IS_TM4C129_RA0) ||                                         \
        defined(TARGET_IS_TM4C129_RA1) ||                                         \
        defined(TARGET_IS_TM4C129_RA2)
        ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                           SYSCTL_OSC_MAIN |
                                           SYSCTL_USE_PLL |
                                           SYSCTL_CFG_VCO_480), 20000000);
    #else
        SysCtlClockSet(SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
                       SYSCTL_XTAL_16MHZ);
    #endif
    
        //
        // Set up the serial console to use for displaying messages.  This is just
        // for this example program and is not needed for ADC operation.
        //
        InitConsole();
    
        //
        // Display the setup on the console.
        //
        UARTprintf("ADC ->\n");
        UARTprintf("  Type: Internal Temperature Sensor\n");
        UARTprintf("  Samples: One\n");
        UARTprintf("  Update Rate: 250ms\n");
        UARTprintf("  Input Pin: Internal temperature sensor\n\n");
    
        //
        // The ADC0 peripheral must be enabled for use.
        //
        SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);
    
        //
        // Enable sample sequence 3 with a processor signal trigger.  Sequence 3
        // will do a single sample when the processor sends a singal to start the
        // conversion.  Each ADC module has 4 programmable sequences, sequence 0
        // to sequence 3.  This example is arbitrarily using sequence 3.
        //
        ADCSequenceConfigure(ADC0_BASE, 3, ADC_TRIGGER_PROCESSOR, 0);
    
        //
        // Configure step 0 on sequence 3.  Sample the temperature sensor
        // (ADC_CTL_TS) and configure the interrupt flag (ADC_CTL_IE) to be set
        // when the sample is done.  Tell the ADC logic that this is the last
        // conversion on sequence 3 (ADC_CTL_END).  Sequence 3 has only one
        // programmable step.  Sequence 1 and 2 have 4 steps, and sequence 0 has
        // 8 programmable steps.  Since we are only doing a single conversion using
        // sequence 3 we will only configure step 0.  For more information on the
        // ADC sequences and steps, reference the datasheet.
        //
        ADCSequenceStepConfigure(ADC0_BASE, 3, 0, ADC_CTL_TS | ADC_CTL_IE |
                                 ADC_CTL_END);
    
        //
        // Since sample sequence 3 is now configured, it must be enabled.
        //
        ADCSequenceEnable(ADC0_BASE, 3);
    
        //
        // Clear the interrupt status flag.  This is done to make sure the
        // interrupt flag is cleared before we sample.
        //
        ADCIntClear(ADC0_BASE, 3);
    
        //
        // Sample the temperature sensor forever.  Display the value on the
        // console.
        //
        while(1)
        {
            //
            // Trigger the ADC conversion.
            //
            ADCProcessorTrigger(ADC0_BASE, 3);
    
            //
            // 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, pui32ADC0Value);
    
            //
            // Use non-calibrated conversion provided in the data sheet.  Make
            // sure you divide last to avoid dropout.
            //
            ui32TempValueC = ((1475 * 4096) - (75 * 33 * pui32ADC0Value[0])) / 40960;
    
            //
            // Get Fahrenheit value.  Make sure you divide last to avoid dropout.
            //
            ui32TempValueF = ((ui32TempValueC * 9) + 160) / 5;
    
            //
            // Display the temperature value on the console.
            //
            UARTprintf("Temperature = %3d*C or %3d*F\r", ui32TempValueC,
                       ui32TempValueF);
    
            //
            // This function provides a means of generating a constant length
            // delay.  The function delay (in cycles) = 3 * parameter.  Delay
            // 250ms arbitrarily.
            //
    #if defined(TARGET_IS_TM4C129_RA0) ||                                         \
        defined(TARGET_IS_TM4C129_RA1) ||                                         \
        defined(TARGET_IS_TM4C129_RA2)
            SysCtlDelay(ui32SysClock / 12);
    #else
            SysCtlDelay(SysCtlClockGet() / 12);
    #endif
        }
    }
    

  • Joseph Haas88 said:
    My expectation of a Tj reading that is something more like 30-40C is

    I have no problem with that expectation, I just get no comfort from the datasheet that the built-in temperature sensor is closely coupled to the processor's junction temperature. If it is more closely coupled to the ambient or not closely coupled to either than you may not see much correlation to the processor's junction temperature (as much as a single junction temperature is actually definable).

    As I said I found the sensor too ill-specified to be useful.

    Joseph Haas88 said:
    The +/-5C spec is known to me, and I am happy with that value,

    With an additional +/-2 C from the A/D uncertainty and additional from your reference voltage uncertainty.

    Joseph Haas88 said:
     For example, I have readings from the LaunchPad that show 10C for Tj.  

    A single reading or two might not be surprising. Would be interesting to see if that's DC or high frequency. Otherwise I agree, unless your reference is quite noisy 16C below ambient seems a bit much, depending on soak time.

    Robert

  • Re: Further beating of an (already) well-beaten horse...

    We've (still) boards bearing LM3S1627 (circa 2010) and quick review shows Tj > Ta - and increasing in separation - with passage of first few minutes after power-up.

    We've employed external T sensors - never content w/the MCU's version...

  • I've tried to load that file, but I can't figure out how to configure the linker to grab the Tivaware libs (I can compile without error, but the linker won't have any of it).
  • OK, I was able to get the file to compile and link. My result is still as before. I'm seeing between 18 and 20C. A temperature probe attached to the top of the MCU package reads 30.5C. By my calculations, the Pdiss of this part is less than 100mW, so the die temp should be within couple of C of the top of the package (assuming that the datasheet Rjc(top) = 0.7 C/W is correct). This puts my delta T measurement at about 10C below what is expected.

    I'm going to look at the power supply one more time just to be sure.
  • Speaking of which, what are the values of your analog and digital supplies?

    What are you using for filtering and buffer capacitors on the analog supply?

    Robert

  • Ah, saw the earlier report on your analog voltage. Still worth checking the filtering and buffering and its AC behaviour.

    Robert
  • Hello Joseph

    At the same time you can try a thermo-stream test by uniformly cooling the device to ensure that the die temperature is as close as possible to the package temperature. The 5C datasheet variation would still be there under thermo-stream.
  • The Vdda supply is measured at 3.29V.

    The 30+ year old scope and crappy probe show about the same noise (some 250mV spikes/ringing at 200KHz) with the probe (+) shorted to probe (-) and then connected to the board ground as when I connect the probe (+/-) across the Vdda capacitor. A very large (180uF) electrolytic across the ceramic made no difference at all (this makes a LPF with a cutoff of 442 Hz vs a cutoff of 795 KHz with the 0.1uF alone). As I noted in an earlier post, if there were PS noise issues, I'd expect a greater range of readings, some of them appearing correct, rather than a bias in one direction or another (my expectation would be different if I had some analog conditioning circuits in the mix, but here, I can't even connect a meter to the sensor, much less put anything in front of it).

    When this design was started, the ADC wasn't viewed as being needed, so there wasn't much effort put into Vdda. A good, low-noise LDO would be preferred, but the feature creep passed that over. Also, don't forget, I noted early on that the ANIN0 input to the MCU seems to be behaving just fine. It is in very good agreement with the pin voltage, so I am pretty sure the ADC is working and playing well with the PS and other possible noise-makers. For the record, ANIN0 is driven by an op-amp that is buffering an LED (with the LED acting as a sensor rather than an emitter). I get about 1.2V in bright room light at the MCU pin.

    I tried heating the device with a desk lamp. I saw a -9C delta between the top temperature and the calculated Tj value with a top case temp of 26C. With the top-temp at 47C, the delta seemed to increase slightly to about -12C. The data is too thready to be sure tho and I didn't have time to let the lash-up fully stabilize (tho it was beginning to do so). Cooling to a controlled temp would be more difficult. A chamber is available, but access is difficult. I have one day next week I might could get access. However, I am reaching the end of my time budget on this, so that may not happen. As Robert indicated, if it isn't behaving, it isn't usable. FYI, I do have an I2C temp sensor on this board. I wanted to try to gather some data on the temperature differential (the I2C sensor is more closely tied to the ambient than the MCU) for future reference -- hence the rabbit hole I now find myself within.
  • Hello Joseph

    I would agree with you. There is clearly an issue with the device not being able to read the temp within the specification. I would suggest returning the device back to TI for failure analysis. But having the external temperature sensor would be a good developmental approach.
  • Amit,

    Since I am not needing an FA, it would be your call as to weather I return anything to TI. If you (TI) feel it is worthwhile, I can assist. Since I have a LaunchPad that expresses a similar response, I would prefer to return that entire board.

    Otherwise, I consider this thread closed. Let me know if you want the LaunchPad for an FA.

    You may now return to your regularly scheduled program.

    Cheers & thanks!
  • Hello Joseph,

    If you consider worth the debug, then yes we would accept the device on the launchpad. Only thing to note would be if the device is a Rev-2 device, it would be considered a production device and be accepted. If the device is a Rev-1 device then it may be dis positioned as pre-production device.