• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 600 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294NCPDT: Consequences of high temperature

Gello
Intellectual 390 points
Part Number: TM4C1294NCPDT

Hi,

I would like to know the consequences for the TM4C129 MCU  of a long exposure to high temperatures, for instance 5 or 6 hours at 65 °C. 

Context: the board is inside an hermetic device exposed to the sun. Temperature inside the device can occasionally reach up to 75°C. Most of device units do not show any working problem, but some samples have problems to get access to the EEPROM and to the on-chip flash memory. For instance, when I try to write to the EEPROM, I get the error 0x200 (I have not found its description anywhere). If I try again, I get the error 0x10 (which corresponds to EEPROM_RC_NOPERM: an attempt was made to write a value but the destination permissions disallow write operations.). Likewise, if I try to write to the on-chip flash memory using ROM_FlashProgram command, I get the error -1.

If I put this device inside and I wait to get it colder, then it works after reboot.

I deem that the two phenomena (high temperature and inability to write to memory) are probably linked, but can anyone confirm it? why do some units work fine and other wrong?

Thank you.

TM4C1294NCPDT

  • 0
    TI__Guru 72500 points

    While temperature does affect flash erase, programming and data retention, the temperatures of 65C to 75C are not high enough to cause programming failures. Could the junction temperature of the device be much higher? How did you measure the temperature? Is the device totally encapsulated in a material that prevents the device from adequately dissipating the approximate 0.5W of power consumed?

  • 0 in reply to Bob Crosby
    Intellectual 390 points

    Thank you Bob for your answer.

    I get two different measures : one from a MS5611 temperature sensor and another from the on-chip internal temperature sensor, and both measurements are relatively similar.

    The device has (so far) no heat sink, but it is relatively empty inside compared to the size of the board. Since the device is continuously exposed to the sun heat, the idea was to have some air to ventilate and avoid overheating.  

  • 0 in reply to Gello
    TI__Guru 72500 points
    The internal temperature sensor should give a very good estimate of junction temperature so I don't think temperature is the direct cause of the failure. Can you measure Vdd in the failing condition? The current requirement increases and the efficiency of supply circuits tends to decrease with increasing temperature. If the Vdd supply drops below the minimum 2.97V, but not low enough to trip the voltage monitor, the flash programming might fail.
  • 0 in reply to Bob Crosby
    Intellectual 390 points

    Thank you Bob for your explanation. 

    I will check the VDD supply and see if there is something wrong.

    Thanks again !

  • 0 in reply to Gello
    Guru 117850 points

    While my firm does not employ your specific MCU - we do supply Motor Control Sub-Systems - which see usage w/in multiple (super-heated) U.S. (south-west) factories - during summer.     Depending upon functionality required - our MCUs span the ARM Cortex range of M0, M3, M4 & M7.     Of note - we have encountered temperatures beyond those you've listed - and early on - also noted, 'Sub-System Issues.'

    Along w/monitoring temperature (as you're doing) - and Vdd (as the vendor proposed) - it is suspected that (even) additional measures (may) prove helpful.    (Indeed - that proved so - for us...)     You may consider:

    • Monitor the MCU's (critical) core voltage.   (believe that's labeled 'Vddc' - for this vendor's MCU)    The (external) load capacitors for that critical voltage are (reasonably) tightly spec'ed - yet wide temperature excursion may 'over-challenge.'
    • Monitor 'all'  voltage sources (assumed batteries) along w/ voltage regulators, references (if any)
    • Your enclosure should 'reflect' light - not absorb it.     A larger enclosure - enabling greater physical separation between 'heat generators' - should also help
    • Consider replacing linear V_Regs w/Switcher V-Regs - should those linear Regs prove (unwanted) heat sources
    • As the temperature approaches 'critical' - consider:
      • reducing the MCU's System Clock
      • shed those 'MCU peripherals' (not) mission critical  (i.e. Kill their clock - even better Power Down (as/if possible))
      • shed those 'non-MCU' devices which add heat ... (if 'mission critical' - power these On/OFF (as required) via MCU GPIO - buffered by a proper FET)
      • order the MCU to one of its lowest power modes - awaking only periodically (or upon stimulus) - should the mission's 'command & control' allow

    These tactics - either alone or (better) in combination - are (almost) guaranteed to extend your temperature-based, range of operation.    

    To gain the greatest insights & benefits - you'll require a capable 'Data Acquisition System' - which can accommodate 'all' of this data.    (and at a satisfactory acquisition rate & accuracy)   

    Our biggest challenge occurred when it proved that the, 'Rate of Change' (NOT the absolute value) - initially caused our system to, 'Lose its mind.'

  • 0 in reply to cb1_mobile
    Intellectual 390 points
    Thanks a lot! I was hoping that you reply because you propose very pertinent solutions.

    I set this post as solved, but if I find out the source of my problem following what you and Bob Crosby proposed, I will post it ASAP.
  • 0 in reply to Gello
    Guru 117850 points

    Gello said:
    I was hoping that you reply because you propose very pertinent solutions.

    Thank you - my friend - much appreciated.    (and NOW ...  I know who my (one) 'fan' really is!)   

    I would advise - 'Why tie/limit your investigation to a single measure?'      Performing Diagnostics 'for a living' - such 'limited/singular efforts' are unlikely to keep our 'doors open.'     And it is well known that one cannot be:  too rich, too thin, nor have too much ... key/critical data!

    Beyond the simple listing of, 'What/where to probe' - a multi-point strategy to (selectively) lower your system's interior temperature - was described.     That's worked 'so well' for us - that it is now,  'de rigueur.'

    As noted:

    • high accuracy measurements
    • at sufficient frequency
    • and sufficient in choice & number

    yield the greatest odds of your diagnostic success...

    I'd add that your performing such 'multiple measurements' (as earlier listed) upon a 'known' working - & then 'known' failing unit - should serve to 'Highlight the area(s) of temperature sensitivity!'      (maybe)

    (one of the most pertinent solutions proposed was the restoral of 'LIKE' ...  disregarded - thus causing myself/others to exit this forum ...  e2e crüe should be rightly proud...)