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 C parts Failing to meet Low Temperature Range specs

Hello Forum members,

I want it to reach out to you guys 

for help an a strange situation with some of the TIVA C parts

specailly the TM4C123GH6PMI parts found on the launchpad

and the TM4C123BE6PMI.

We have a customer board that was design around the TM4C123BE6PMI parts

and the Launchpad with the TM4C123GH6PMI was use to develop the firmware

for the customer board.

Things were working great until, the customer reported board failures due to low temperatures

on the field.  There report was that 20 boards  they were initally field testing fail to operate when

the temperature in the environment on which the boards were installed had reached -5 C.

They also reported that they got the boards to run again when they heated the boards back to normal

room temperatures.  

So we ask our customer to take power supplies measurements specially the TM4C123 power supply

of 3.3V and its VDDC core voltage of 1.2V under the failing temperature.  They reported that the votlages

were found normal as when the boards runs in normal temperatures.

So, we started testing a couple of the customer boards here at the office by running the firmware

while the boards were expose to freezer temperatures of 0-18C or 0 F.  Sure enough after a few minutes

the boards stop running the code.  So while it was inside the freezer, we took some measurements and found

the power to the mcu to be normal 3.3V and the core voltage (VDDC) to be normal of 1.2V, we also probed the 

crystal with oscilloscope and found it to be working, but no code running.

Our first trials involved the TM4C123BE6PMI chips and found each one we tested to fail once expose to -18C.

So, then we order the TM4C123GH6PMI, which is the same chip use on the Launchpads, to replace the

TM4C123BE6PMI chips, and run it in the same cold environment.  For our surprise, the TM4C123GH6PMI failed 

too at -18C and 0F temperatures.

To make sure there that our customer board was not at fault, we decided to get to then test the Launch Pad

board. So we then loaded the firmware and run it on the same cold temperature of -18C.  To our surprise, we

found the launch pad to also fail under same cold temperature.

In trying to get to the bottom of what is happening with these chips, we search the Errata documents on TI's 

website to see if TI has found any issues with peripherals on the chip causing failures at cold temperatures.

But we found nothing on this matter.

So, what to do next?

Well, we decided to experiment a little to see if we could get an answer as to what is 

happening with the chips.  We took, the launch pad connected to CCS 5, load the code and debug.

Using the chip internal temperature with TI's formula: TEMP = 147.5 - ((75 x (VREFP - VREFN) x ADCcode) / 4096)

to take quick temperatures readings as we freeze the mcu and send it out to the uart via launchpad.

Before we show any results we have to explain what peripherals we are currently using on the TIVA C parts 

in question here.

1) UART0 via Pins 17 and 18, configure at 115200 baud, 8 bits 1 top bit no parity

2) PWM1: PWM2, PWM3, PWM4, and PWM5 on pins 23, 24, 28, and 29 respectably.

    Generator 1 for PWM and Generator 3 for ADC timing

3) PWM 1 Generator 3 interrupts to generate our 1 ms interrupts

4) ADC0 at 1MSPS with Sequencer 0 processing 8 channels including Internal temperature sensor, and Sequencer 1 handling 4 more channels

5) ADC Sequence 0 Interrupts 

6) ADC Sequence 1 Interrupts

7) UART0 Interrupts

8) GPIOs of course.

OK. now here is what we find.

1) As long as the temperature is below 0 C the PWM channels M1PWM2 and M1PWM3 are turn off  and they don't come back on until the temperature gets above 4 or 5 C base on the internal mcu temperature sensor 

2) The UART0 data transmitted stops when below 0 C, but starts transmitting back once above 0C.

3) ADC0 seems to stop reading below 0 C.

Now, here is the question.

What is failing first the ADC0 or the PWM1?

Since the PWM1 uses the data returned back from the ADC0 to turn run its PWM channels.

Or could it be that the Interrupts fail and not the ADC0 or the PWM1 which depend on the interrupts

to update the data from the ADC0 and the Duty cycle for the PWM1 channels.

Has any body encounter something like this with the launch pads mcu?

If any body is interested in trying the same experiments we did here is the firmware bin file

to load into the TIVA C launchpad.

0005.MES896_I2_V5.zip

  • This is a little worrisome.  I know we have done some measurements after cycling using a different part but I don't think we tested at sustained lows.

    No answers but a couple of suggestions/questions

    Have you controlled for humidity?

    Consider toggling a pin directly in the software.  It would give you one more point to look at.

    It might be worth a check running of of the internal oscillator as well.

    Simpilify your software so that you are operating a polling mode only.  Maybe just send an endless stream of incrementing numbers out the serial port.  If that works there may be something more subtle happening.

    If it was only your own boards failing I might check that all the pads were well soldered.

    I have found that even ICs rated only to zero generally will operate below zero so this seems odd.

     

    Robert

  • Hello Robert,

    Good Suggestions.

    I will try all your suggestions to see if we can isolate what is happening here.

    Here is an update.  As of this morning, we decided to stress the chips in question

    with high temperature by heating them with a heater.

    Initial testing at higher temperature show PWM signals changing Pulse Widths causing motor speed to increase  as the temperature increased above +42 C or so.

    Now as to answer your question about humidity control, we have yet to conduct a test with humidity control.

    But for sure we will look into that.  

    Also note that the Launch Pad also fail the same way as our board at higher temperature too.

  • Moises,

    We have not encountered the issue you are describing, but you are doing a good job trying to isolate the issue.

    The parts are qualified to run at the temperatures specified in the datasheet.  However, successful operation requires a system level approach so that the entire board can function correctly.  All parts even down to the capacitors must have sufficient margin at room temperature to be effective at temperature extremes.  As the LaunchPad is primarily a low cost evaluation tool intended for an engineer’s desk this level of design for extreme temperatures was not applied.  However, we have successfully seen TM4C123G LaunchPads operating at -18C ambient and 60% humidity.

    Please conduct the test suggested by the other forum poster.  Create very simple program that uses the internal PIOSC and does nothing more than toggle a GPIO.  The project0 example for the LaunchPad is a good place to start.  Test this project at cold temperature.

    Also make sure that your temperature chamber is humidity controlled.  Condensation can cause leakage paths between pins of the device which will cause failures.

    Finally it appears you are using the internal ADC temperature measurement.  This measures core junction temperature which will in general be warmer than ambient.  Also there is an errata for the device which states that the first two samples of the internal temp sensor must be ignored.  The workaround is to sample the internal temp sensor three times consecutively without interruption and discard the first two.  See the latest rev of the errata specifically ADC#09. 

    A precision external thermocouple is recommended to determine actual ambient temperature.

    Is it possible to have the debugger connected while in the low temp environment?  This could identify if a fault is occuring.  By default, the fault handler sends the device into an infinite loop until reset.

    -Joel

  • Our group has used multiple ARM MCUs - from multiple vendors - and has met (and exceeded) your operating requirement with a predecessor MCU (LX4F) from this vendor.  (also - have met/beat your spec w/MCUs from others.)

    Are all of your DUT (devices under test) from the same date/lot code?  May prove revealing - I'd try for latest/greatest. (likely requires survey of all disty stock, multiple distys - and distys will "love" such request...)    

    To my mind - now that issue has revealed - would it not be best to see if your MCU can meet your operating requirement by loading the simplest, smallest code - such code enabling easy monitoring for correctness?  Port output (@  2 - 3 Hz) - across several ports - each monitored by Leds - should suffice and be quick/easy. 

    Why this method?   If your MCU fails during this far less demanding test - many (most) of the chicken/egg issues you properly, earlier raised - become moot.  Instead - it may be the MCU, other components, your board implementation - possibly any one alone - or multiple, in combination!  (welcome to the "joy" of real world...)  We have found this, systematic, incremental discipline of enabling one peripheral at a time - and carefully monitoring/logging - most always to yield the best, fastest results.  When all peripherals "pass" individually - only then would we attempt to introduce multiple peripherals to the fray.

    Should this simpler, more methodical/bounded test method fail @ step one (Leds toggling from multiple ports) you likely should double check all critical components connected to the MCU.  All must meet/exceed your operating temperature requirements - and be w/in MCU spec - as well.  By running from PIOSC - as earlier suggested - you eliminate xtal osc circuit from, "list of suspects."   Makes good sense - imho.

    If failure still occurs @ this very reduced SW test level - running under PIOSC - you may consider use of a proper encapsulant (yes - ugh!) - carefully applied per maker's spec - along each side of the MCU - covering all MCU pins and extending perhaps 0.100" beyond the MCU.  Apply this only after your pcb is scrupuously clean, contaminate free, and dry - and in close conformance to maker's instruction.  We used this in critical applications - especially under cold & high humidity conditions - and when well implemented has worked extremely well...

  • Joel,

    Thank you so much for your suggestions and comments.

    and thank you all members of the forum for all your suggestions and points.

    We when back to our code and did as suggested by many of you including

    Joel and other members in the 43oh forums and that helps us a lot into

    ping ping pointing out the issue.  

    After conducting short test on short parts of the firmware code through CCS 5 and debug

    sessions we were able to ping point the problem to one piece of code that was blowing up

    and causing the temperature faults to trip even though the actual temperature around the chip

    was not even close to being a trouble temperature.  We found that our equation calculating the

    temperature was missing a factor of 10.

    We have corrected the equation and seems to be working now at below 0C temperatures.

    What a monkey.

    I will conduct more test inside the freezer just to make sure its OK.

    Than you so much to all members of the forum that help out with their great suggestions

    and thank you Joel for your help too.

    This is a great relief for us and we don't have to redesign the board.

    Now, for the high temperature found to fail at +42 or so C I think we are OK there to but will test again

    and will report results.

    Thank you all.

  • Posts have just crossed - should your device be expected to operate for long periods at such temperatures - and should temperatures transition suddenly - humidity may invade and over-challenge your more pristine - lab/chamber test conditions.  Real world is always more harsh/demanding than lab/bench/chamber.  (not to ask - how I know)

    Fine pitch devices (as all of these MCUs now appear) are vulnerable to pcb cleaning residues.   Your "appropriation" of methods - long used successfully by "environmentally challenged" others - may provide a most necessary, further safeguard - unstated thus far, here... 

    Minus this additional recognition & acceptance - "monkey" you fear may return - garbed in thermally active coat...

  • Yes,

    I feel like everything in the mcu world is against me right now.

    What do you mean 

    "thermally active coat..."

  • Not quite the comment I was seeking - I'm jammed - try to inject some humor to raise my/staff's energy.  A cold "monkey" would benefit from a, "thermally active" coat/cover.  (you introduced the monkey - this reporter simply/properly clothed ...)

    My intent was that you instead respond to the suggestion to simplify - KISS - and test as described.  And - if your board is really so thermally stressed - proper "encapsulant surround" often proves worthwhile...  I believe that the brevity of your low-temp test may not prove fully conclusive - and that further, extended temperature testing is indicated...

  • Moises Escobedo said:

    report was that 20 boards  they were initally field testing fail to operate when the temperature in the environment on which the boards were installed had reached -5 C.

    Above quote - your initial (opening) post.   Yet later, when you report success - it's stated, "We found that our equation calculating the temperature was missing a factor of 10."  And - taken in combination - that (unsigned) "factor of 10" suggests that your MCU was reporting -5°C * 10 = -50°C or -5°C * -10 = +50°C. (+45°C, I suspect) 

    Neither (-50°C nor +45°C) seem especially convincing - answers/results generated too quickly may not prove long lasting...

    While it's good that the original complaint appears resolved - the cause/effect mechanism - at least as presented here - seems in need of some further analysis...

  • I agree that further testing is needed.

    and we will test further, but initial testing

    after fixing formula has return positive results.

    although your point its well taken.

  • And - depending upon duration, severity of cold, slope of temperature delta, (i.e. likelihood of condensation) you may wish to give some/slight consideration to applying (tech term follows) nice "schmear" of proper encapsulant around MCU's perimeter - such that all MCU pins and perhaps critical components as well - are sealed/protected. 

    Your study should find/reveal those tech specialists - producing volumes of MCU driven devices - for use in severe/hostile environments.  Suspect their MCU/board - treatment/practices - provide an especially sound guide for you...

  • Moises, I am confused by your report.

     

    Do you mean that the temperature scaling was off by a factor of 10 and the actual temperature was far colder than that reported when it failed?  Surely that would show up on your thermometer in yor cold chamber?

    Or do you mean that the temperature scaling was off by a factor of 10 and the calculation was causing the processor to lock up?  That's not particularly a source of relief either unless you've found and fixed another problem related to the reported temperature.

    Robert

  • Ahh - perhaps TIVA's don't like to divide by zero?

     

    Regards,

    Dave

  • @ Dave,  (others - sorry - long-term forum "insider stuff," here...)

    The incandescence of your analysis is eclipsed only by the "warming effects" of my - long preferred - light/heat source...