CCS/TM4C129ENCPDT: Early power failure detection and writing data to EEPROM issue

Normally I would "gently protest" your use of "Expecting" - which proves as destructive as "Urgent" - and most always insures that your post is addressed "last" (if at all)!    

That said - your post is so well written - and includes such key detail - that I will (this time) bypass my "rejection instinct."    (Do note that the forum must support "Forum Neutrality" - and it proves improper to "Expect or deem Urgent" - those earlier in the que have rights - do they not?)

You can likely, "gain more time" by detecting "Power Failure" even earlier than you do now.     Undescribed is your method of such detection - yet improved analog accuracy - and location of the detection mechanism "prior" to the filtering components - makes sense - does it not?

The "rate of change" of the "pre-filtered" supply may also be monitored - and provides an "Earlier Warning!"     Our firm employs such methods in many instances - due to the "extra time" such method provides.

You describe, "Switching Off the supply - and then noting the MCU's Reset pin "immediately" decaying to 0V."     Would this report be more complete if you scope monitored - and presented here - the voltage waveforms of:

• your "pre-filtered" tap/detection point which signals "imminent power failure"
• your "filtered" supply - which "feeds" the MCU's 3V3 regulator
• the 3V3 regulator's output 
• the MCU's (suspect) Reset pin

It is normal to "pull-up" the Reset pin (usually 10K or so to 3V3) and tie a 0.1µF cap from Reset to Gnd.      If that's what you've done - such "multi-channel" voltage display (as suggested) - would enable those here to determine if the MCU's Reset is (on its own) driving to Gnd!     (such seems to be your suggestion)     Working w/many ARM MCUs (many vendors) I do not know that answer - as regards your device.

It is always "distressing" to learn of our clients - or forum posters - who have "locked into" a (pardon) "so restricted a design - which cannot accommodate" small/simple/FASTER "off chip" non-volatile, storage solutions.     Most any MCU's "EEProm" proves "unable to compete" w/ "Purpose Designed/Developed devices!"      Thus - you have "backed yourself into an (avoidable) corner" - have you not?

It is "expected" that you've "Not supplied too many of these "over-challenged, MCU and MCU only" style boards" - that's true is it not?          

Provisioning a new board - with the "option" for a "FASTER, More ROBUST, non-volatile memory" (which you may NOT have to fill/populate) is the most "valuable" (if I may) suggestion I can offer...

Again - you (may) get lucky - and be able to employ the (very) compromised EEProm-like "solution" offered by the MCU.       Yet producing the new board (with the addition of "a proper device") does not prevent your attempt to someway/somehow "cobble a solution."    

From firm's/my (recent & bulk) experience - most such "data saving needs" will only GROW in time - the solution I've offered (very) well - and uniquely - accommodates such expansive (i.e. "MCU Killing") "REALITY!"

Hi cb1_mobile,

Thank you so much for your reply. Please let me check and I will give my complete list of observations regarding this issue.

cb1_mobile said:

Normally I would "gently protest" your use of "Expecting" - which proves as destructive as "Urgent" - and most always insures that your post is addressed "last" (if at all)!    

Yes...I understand and thank you for pointing out. From next time on wards I will try to avoid that..!! :)...

Thanks and Regards,

Renil Raju

Thank you as well.       "Forum Neutrality - much like "Net Neutrality" - is a worthwhile goal.       Those seeking to "jump ahead of others" (signaled usually by "Expecting and/or Urgent") should route their "high volume" requests to the local Sales Office - where such "special treatment" (if & when warranted) will be granted.

Kindly: "Beg, Borrow, Acquire (legally) a scope - if only two channel provide multiple screen caps:  "both before "Power Failure" and then (ideally) at your (existing) "Failure Trigger Point."

• 3V3  AND  your Reset pin
• your power supply "pick-up/tap point" (Pre-filter) which intends to provide, "Supply Failing" voltage  AND your "Post (after) Filter" voltage

Best of all - a 4 channel scope - which supplies "ALL four voltages" both before "Power Failure" and then (ideally) at your (existing) "Failure Trigger Point."       Note that not all of our clients possess "4 channel scopes" - you should be able to employ TWO - "Two Channel Scopes" - which are "Triggered from a common signal!"    (all time scales & scope settings (and scope grounds) should be equal)    

A logic analyzer (may) also work - but check to insure that the analyzer's "capture rate" is "up to this task."

Again - much is to be gained by "accepting the fact" that  "Purpose Designed/Developed Devices" far outperform (most always) those, "Tortured/Cobbled MCU implementations!"  

I will make three comments here and then let you follow cb1s advice

Renil Raju said:

My application is to store different parameters(like counter values, date time etc) to internal EEPROM memory of the microcontroller whenever a power failure is detected

I believe this approach to be a bad solution. It's complicated and error prone.

Renil Raju said:

I tried the following things to solve my issue:

Two things you need to consider.

• Your design time for power backup is low. The EEProm is new and so are your hold-up capacitors. As they age the EEProm will take longer to write and the capacitors will lose their ability to hold charge. You need to look at the worst cases for both which will increase your required hold up time*.
• Your tests are unlikely to reveal the worst case even for the current arrangement, you will need to add considerable margin.

Finally, you need to consider how you detect corruption from whatever cause and maybe consider mirror copies as well to recover from corruption. This will add to your required hold-up time.

Robert

* Really look at the EE worst case timing. It's horrid. I'd put on an external FRAM and avoid more than a minimal hold-up.

Robert - well said - we are in close agreement.

Especially the "linkage" (very) failed "MCU as Kitchen Sink" and your, "Complex plumbing ... stops up the drain!"

Simply glance @ the "expanse of errata" - and the "special use restrictions & strict conditions" - "Step right up folks...")          Or NOT!

We have (both) suggested "proper/known/errata-free, external storage" - avoiding, "Tortured/Cobbled" - even when FREE - especially when FREE!

R Sexton said:

The EEPROM on the Tiva is quite slow - it takes on the order of 5ms to write data

Recheck the datasheet, I believe you are underestimating the worst case. I would expect 5mS worst case for external EE, although they've improved to better than that for fast ones.

R Sexton said:

You can write FRAM at 1MHz over I2C.

Or 20MHz (with good layout etc..) on SPI with the additional advantage of a considerably simpler, less error prone SW interface. 2-5MHz is certainly achievable.

More to the point, given the FRAM lifetime, there is no need to wait until powerdown to write. Keep the FRAM updated an on powerdown just complete the last write. The constraints for that are considerable fewer.

Robert

And I count 3 advising moving the time critical memory off board