• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 32 subscribers
  • Views 3319 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.

TM4C1294NCPDT Power & Wake Mode - Confirmation, Please

Thomas Spivey
Prodigy 120 points

Other Parts Discussed in Thread: TM4C1294NCPDT

Hello,

I am designing a product using the TM4C1294NCPDT that requires use of the hibernation module with a back-up battery to maintain time & date in the event of a system power loss.  I was considering using some sort of voltage detector on the main VDD, whose output would go low when VDD was present, and connecting this 'VDD_Present#' signal to the WAKE# pin.  Is this a good method to wake the MCU when power is restored?  If not, can someone kindly suggest the appropriate method for automatically waking the MCU from hibernation??  Thank you!

Tom S.

  • 0
    TI__Guru 59540 points
    Hello Thomas,

    The method you mention sounds fine to me. I might suggest you look at using a voltage monitor with a power good signal or even an LDO with a power good signal connected to the wakeup pin. This would help in also indicating when to enter hibernate on a change in pin state during power loss.
  • 0 in reply to Chuck Davenport
    Prodigy 120 points

    Thank you, Chuck.  Perhaps I can find a suitable LDO with a power_good# signal, which may be less expensive that my current LDO + separate comparator.

  • 0 in reply to Thomas Spivey
    Prodigy 120 points

    I wasn't able to locate an LDO with a PG# output that was cheap enough.  How does this approach look?  VDD is 3.3V, and the MIC803 (suitably cheap) releases RESET# at 2.93V.  I lose 10mV maximum across the 1k resistor due to the worst-case operating current of the MIC803, which shouldn't be a problem.  When RESET# is deasserted, MOSFET Q2 is allowed to turn on, asserting WAKE#.  This seems to kill two birds with one stone - I get a timed, voltage-verified reset signal, and a voltage-verified wake signal.  Comments, please?

  • 0 in reply to Thomas Spivey
    TI__Guru 59540 points
    Thomas,

    I am confused about what you are needing. From what I can tell, you have fixed main power source (3.3V VDD supply) that may go away. When it isn't present, you would operate off of the battery supply (also 3.3V) with the TM4C in hibernate mode but maintain RTC operation during hibernate. Correct?

    You are looking for a mechanism to #1) detect for the presence of the main 3.3V supply. #2) Trigger hibernate when no main VDD is present, and #3) Trigger wake up from Hibernate the main VDD is restored to 3.3V. Again, is this correct?

    If this is true, then why wouldn't a simple FET be suitable for switching between main and battery power? Also, why wouldn't the ADC input of the TM4C be suitable to detect absence of the main VDD? and finally, why couldn't the 3.3v from the main VDD be used as input to the wakeup pin?
  • 0 in reply to Chuck Davenport
    Prodigy 120 points
    Hello Chuck,

    This is my first design using the Tiva TM4C1294NCPDT MCU, so it is entirely possible that I have missed something.

    The Tiva MCU has a separate power domain (VBAT) for the RTC, which is powered from the rechargeable lithium cell. The charging circuitry isolates the VBAT from VDD; when the system power is lost, only the RTC remains powered. With VDD gone, the MCU won't be doing much of anything. When the power is restored, the MIC803 will provide a timed, voltage-verified reset. I wasn't sure if I needed to 'wake' the MCU with the WAKE# signal, but just in case I did, I added the inversion circuitry so WAKE# is pretty much the opposite of RESET#.

    Do I need to trigger hibernate if the VDD simply disappears?

    Thanks!
  • 0 in reply to Thomas Spivey
    Guru 117855 points

    Pardon but all efforts here seem to neglect the advantages of, "Detecting the pending loss of power earlier - rather than later."   Classically many such designs measure the input voltage (before) the first stage voltage regulator.   This enables the earliest possible detection of any "pending power loss" which provides the greatest time for the MCU to take appropriate save/store/configure actions.

    Methods presented earlier shorten the time for the MCU to react - I believe the best results to stem from a far earlier detection of pending power loss...

  • 0 in reply to Thomas Spivey
    TI__Guru**** 244440 points
    Hello Thomas

    Did you check the section of the datasheet under Hibernate Chapter for "Arbitrary Power Removal". The device automatically hibernates on power loss and wakes up when power is restored under certain conditions.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 117855 points

    Hi Amit,

    Is it not true that such "automatic hibernation" (by your MCUs & those of others) adds (some) element of risk - and that, "Entry into hibernation - and escape therefrom" (may) not fully/properly occur - under all conditions?

    Far earlier detection of pending power loss - via monitoring of the filtered DC routed to first stage voltage regulators - long has proven, "Gold Standard" for "Safe, orderly, and "predictable" MCU shut-downs and re-awakenings!"

    The compression of time to  enable such critical detections (via "automatic") - and then to implement full/proper & so vital MCU activities - and then to fully/properly recover - demands the (hedge) "under certain conditions!"   Can those (unspecified) conditions be fully met - each/every time - really?   

    Automatic (may) make sense - but users must evaluate (real) risks vs. (hoped for) rewards...

  • 0 in reply to cb1_mobile
    TI__Guru**** 244440 points
    Hello cb1,

    The conditions for automatic hibernate are listed in the data sheet and we have validated that the device does behave as per the specification when Power Failure on the VDD rails occurs and when the conditions are not met, then it is treated as regular Power On Reset.

    The following point from the poster "Do I need to trigger hibernate if the VDD simply disappears?" made me believe that the implementation was being complicated more than what was required. Having an external Voltage Supervisor to release the main reset would provide for a clean power up, but nothing to meet the requirement of the specific case.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 117855 points
    Thank you, Amit.

    Firm/I "stand" by the classic (and far earlier) detection of pending power loss - which provides much greater time for a controlled, comprehensive, system shut-down. (note that it is not always (and only) about the MCU! The extra time provided by the "older, more classic method" enables other devices to be properly commanded...)
  • 0 in reply to cb1_mobile
    TI__Guru**** 244440 points
    Hello cb1,

    I am not against a graceful pending power down, I am just contemplating the arbitrary power loss case.

    Regards
    Amit
  • 0 in reply to cb1_mobile
    Prodigy 120 points

    Hello cb1,

    I understand what you are saying, and I have designed numerous products where the MCU needed to gracefully handle power transitions.

    However, this case is different.  The product is powered from an external 5V/12A power supply, which is powered from the AC line, and only the RTC function is battery-backed.  There is no need for a graceful power-down, no state information needs to be saved.  The MCU can just die.  All needed state information was previously stored in EEPROM, and will be reloaded when the power is restored.

    My prime concerns are that the MCU resume operation normally when the power is restored.  I suppose it wouldn't kill me to include an ADC channel that measures the input to the VDD regulator . . .

    Tom

  • 0 in reply to Thomas Spivey
    Guru 117855 points
    Hi Tom,

    Understood - you are a skilled/serious user - I wanted to make the case for the, "earlier, pending power failure" advantages.
    Do note that such, "Losses of Power" often occur w/transients & other gremlins.

    As you've "no insight" into such power failures - and your needed state info "eats time - due to its EEPROM storage media" how do you preclude a power failure during (any) of those vital EEPROM writes?"

    I understand vendors driving their devices to, "Kitchen Sink" (do everything) expansion. Yet - sometimes - past (classic) methods prove best. That would be firm's/my (unrelenting) recommendation...
  • 0 in reply to cb1_mobile
    Prodigy 120 points
    Hello cb1,

    Serious? Yes. Skilled? Well, that remains to be seen . . .

    Fortunately, those EEPROM writes are not "vital" - they are just user-set preference information, and if in the unlikely event that power was lost during a write, upon power-up, the MCU would reload bad data from the EEPROM, which would be rejected due to a failed checksum. The MCU would then continue to operate with default information contained within the program flash. Since the time required for any of these operations are undetectable at the human level, they don't matter. I don't believe the user would complain that the power-up sequence required an extra 10ms . . .

    Tom