• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 31 subscribers
  • Views 1511 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.

Best way to detect a power loss on TIVA TM4C129ENCPDT

Bill Sousan
Intellectual 380 points
Other Parts Discussed in Thread: TM4C129ENCPDT

All,

      We are using the TIVA TM4C129ENCPDT and we need save the status that a power loss has occurred.  So I am looking for the best way to setup the TM4C129ENCPDT to let the application know the power is going down - then I plan to write the timestamp in EEPROM of when it occurred.  Is there a way we can setup an interrupt handler that will be triggered once the main power (VDD?) has dropped below a certain threshold?  

     I looked a bit at the system control for brownouts but not sure if this is the way to go?

Thanks,

Bill

  • 0
    TI__Guru**** 244400 points

    Hello Bill,

    How fast is the power going to drop? Typically the BOR would be the correct way to generate an interrupt and use the same to write to an EEPROM. However there is definitely detection time execution time and the time that it takes for EEPROM to be programmed, which must be considered.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 380 points

    Thanks.

    Yes I realize that.  Our hardware guy has added some capacitor (similar to a supercap - but not as strong) to add a bit of time to complete the write.

    Also, we have added a battery to the VBAT connection for the purposes of keeping the real-time clock running if power is removed.  So I don't know if this configuration would help any?

    Thanks,

    Bill

  • 0 in reply to Bill Sousan
    TI__Guru**** 244400 points

    Hello Bill,

    The worst case total time needs to be computed as follows

    1. Detection Time for BOR circuit

    2. Interrupt Handler execution

    3. EEPROM Operation.

    While the fist 2 would be few us, the 3rd one is a variable based on the EEPROM Endurance and the copy buffer invocation if the EEPROM needs to be written. It could be as high as 60ms at 10% endurance. So does the capacitor store enough charge to hold off for 60ms minimum.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 27665 points

    How long is #1 Amit?  I couldn't find any documentation on that for the TM4C123.

     

    Robert

  • 0 in reply to Amit Ashara
    Intellectual 380 points

    Thanks.  Yes I will check this.  However, Now I am trying to get the BOR interrupt to be generated but having problems with the operations.  Here's the steps  I am doing so far:

    1.      ROM_SysCtlVoltageEventConfig(SYSCTL_VEVENT_VDDBO_INT);

    2.      Created short interrupt handler that beeps a beeper and inserted it into the handler with this comment:  // System Control (PLL, OSC, BO)


    3.    Using power supply I slowly turn the voltage down on VDD pin

    But the interrupt handler never appears to be called (no beep).

    Am I missing more configuration settings to make this occur?

    Thanks,

    Bill

  • 0 in reply to Bill Sousan
    TI__Guru**** 244400 points

    Hello Bill,

    To enable the interrupt  generation, the following need to be done

    1. Change the BORCTL to generate Interrupt instead of reset

    2. Enable the IM in the System Control Space

    3. Enable the Interrupt in the NVIC

    4. Map the Interrupt Handler

    If you can share the code, it would be faster to check

    Regards

    Amit

  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points

    Hello Robert,

    It is of the order of 0.25 to 1.95us for BOR0 and 0.75 to 5.95us for BOR1.

    It is given in the Reset Characteristics table in the electrical section of the data sheet.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 380 points

    Amit,

        Forgot to add the Enable the Interrupt in the NVIC.  Now it works!

    Thanks,

    Bill

  • 0 in reply to Bill Sousan
    Guru 117855 points

    May I suggest another method of detecting - and then (perhaps) more efficiently responding - to an imminent power loss? 

    Several of our firm's systems run from unstable power sources & (against our advice) may not include battery back-up.  Experience has taught that a superior method - one which provides the "earliest" warning - is to monitor the input power voltage - far in advance of the MCU's voltage regulator.  Normally several volts of voltage drop may be accommodated by this method - far exceeding the more limited voltage range available @ the MCU.  (any vendor's MCU)

    On occasion we add intelligence to detect the, "rate & degree" of change of this power voltage drop.  This guards against, "nuisance trips" - and may even enable the "switch in" of added voltage storage devices.

    Believe that, "extra MCU" methods/components - as described herein - may further enhance the detection & response to power voltage drop-outs...  The MCU as, "kitchen sink" - for any/all design requirements - may not always prove best/brightest...

  • 0 in reply to cb1_mobile
    Intellectual 380 points

    Thanks!  I tried your method and it works!  Yes our design actually has 24VDC input power and I monitor this line from within a timer interrupt and it works great!

    Thanks,

    Bill

  • 0 in reply to Bill Sousan
    Guru 47900 points

    Bill Sousan said:
    Thanks!  I tried your method and it works!

    Thought so - we have used such methods for years - our firm's doors remain open proving (some) success.

    Greater voltage spread - again far ahead of the MCU - surely proves superior than the very much compressed range provided by the MCU.  Again - not a vendor weakness - but (instead) a case of the MCU meddling where it is at grave disadvantage!  (i.e. knowing when/where to employ the MCU vs. external system elements is important...)

    Might you better "signal" the correctness of this "best/brightest" method via proper award of, "Verify?"  (you've done so for vendor - yet vendor's {MCU as (inefficient) kitchen sink} method suffers  limitations overcome by method I've detailed...)

  • 0 in reply to cb1
    TI__Guru**** 244400 points

    Hello cb1

    A vote of thanks and "Verify" sign from my side

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 47900 points

    Thank you, Amit.

    MCUs indeed have made great strides from our past 68xx, 8051, Z8 etc.  Yet - System Design should not be under valued - often the proper, "analysis & segmentation" of "System Tasks" vs. "MCU Tasks" yields the optimum solution.

    Far greater, "voltage spread" - achieved "ahead" of the MCU (in poster's case) - steers this application win to the, "System Side."