• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1030 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C129XNCZAD: Hibernate module battery draw with Tamper enabled very high

William James10
Prodigy 250 points
Part Number: TM4C129XNCZAD

With VDD removed & the Hibernate module configured for RTC & Tamper (single input), it is drawing over 70uA from the battery (coin cell).

The data sheet (Table 31-67. Current Consumption) doesn't have an explicit listing for:

I 'HIB_Tamper' with:

VDD3ON NOT enabled

VBAT = 3.0 V

VDD = 0 V

Only the I HIB_NORTC & I HIB_RTC values are shown, and they are under 2uA !

So, what is the expected battery draw with Tamper enabled? and is 70uA excessive?

Thank you.

  • 0
    TI__Guru 72500 points
    I would expect the current to increase only by what is used by the TMPR[3:0] pins. Are you able to get below 2uA in hibernate mode when you do not enable the tamper sub-module?
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Bob Crosby said:
    Are you able to get below 2uA in hibernate mode when you do not enable the tamper sub-module?

    That's excellent guidance!           (perhaps should not have escaped poster...)

  • 0 in reply to Bob Crosby
    Prodigy 250 points
    Thanks for the quick response.
    The hardware guy found it Friday then went on vacation. I (the firmware guy) am getting things setup for him to measure variable configurations when he returns Mon. (I regretfully, don't have the proper test equipment in my location).

    We use 1 tamper pin with internal pullup, and he verified only it has power, no others, as expected. Then left..

    Also we don't use 'hibernate' mode (call HibernateRequest()) as our electronics do not switch power. We use a supercap to provide several seconds for any cleanup, then rely on the hibernate module for RTC & tamper detect. From the documentation, it does not appear that the hibernate module 'hibernates'. Is that a requirement? If so, we would need to re-layout our board to enable a wake signal on VDD return.

    All I am looking for right now is, if there is a spec of what draw we should expect with tamper enabled.
    Thanks again
  • 0 in reply to William James10
    Guru 117855 points

    First - pardon - outside firm/I,  "Feel your pain."

    That admitted - my having past worked @ a similar "semi-giant" revealed that such (exacting) detail may not (in its entirety) be available.      (such is my sense - based upon facts revealed - thus far)

    Indeed your desire to "progress" is applauded - yet it is believed that your, "best & most convincing answers" would arrive from proper measurements - conducted under your "unique conditions" - on your actual board(s).      At times - such may (even) enable the "discovery" of enhancements - which "escape" normal data-sheet publication...

  • 0 in reply to cb1_mobile
    Prodigy 250 points

    Was able to run some tests & It appears we may have blown out portions of the tamper module on the test boards.

    Fresh board, no power, hibernate module battery current draw tests show:

    ~1.3 uA with just RTC enabled (in spec)

    ~2.3 uA with RTC + 0-4 tampers (w pull-up) enabled (acceptable)

    Much better than the 100uA originally seen (on two boards).

    Unless further testing proves otherwise, Appears tamper subsection has ~1 uA draw.

    Please mark this closed.

  • 0 in reply to William James10
    TI__Guru 72500 points
    Thank you for posting this follow up with the results.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    And - is it not (most always) true ... that such, "highly detailed, data finds" result from, "Proper user measurements - conducted upon their own boards/devices"  - under their, "expected operating conditions?"

    Silent in this thread - but likely of use/value to others - is poster's description of the (likely) cause of the reported, "Damage to the Tamper Module."

    He who does not, "Provide such history" - likely  condemns  "others" - to repeat such history...      (credit "Santayana" for the "original" ... cb1 for the modified (more appropriate for here) version...)

  • 0 in reply to cb1_mobile
    Prodigy 250 points

    To close this out, the issue appears to be with PM5, it was being used as a GPIO & had ESD protection, but obviously not sufficient.

    PM5 continued to perform as a GPIO, but if configured as a tamper input, it would not trigger. Surprisingly with power off (battery only) it did not show any voltage or current, so it seems to be purely internal damage.

  • 0 in reply to William James10
    Guru 117855 points

    Thank you - your description appreciated.     (Yet - my having past worked @ similar semi-giant - the claim,  "obvious ESD insufficiency of PM5" - at least to me - proves, "neither obvious nor conclusive.")

    Identification of those "outside-world, ESD-rich" signal sources - inflicted  "only upon PM5" - would,  "make a stronger case for ESD" - as the "sole and "real" cause.

    Prototypes - and their handling - during ALL aspects of  "design/development"  frequently encounter "mishaps!"    Ascribing "ESD" (alone) - until that device is,  "decapped & viewed/studied" - may not prove a "fully correct or complete" diagnosis...

    Again - your response & description were (and are) thanked & appreciated.