RTOS/TM4C1294NCPDT: EEPROM write on power failure Not happen.

This is how read and write EEPROM Data.

///// structure for data writing and reading ////////
typedef struct vol_vars_flowmeter_struct_prototype
{
  uint64_t digin_counter_value;

}STRUCT_VOL_VARS_FL_METER;

// Volatile Varibles structure

typedef struct volatile_vars_prototype
{
    char start; // dummy variable


    STRUCT_VOL_VARS_FL_METER fl_meter[6];

    uint8_t dummy[8];//this is kept to make EEPROM image copying & retrieving routines to work correctly which read & write to EEPROM memory in multiples of 4 bytes
}STRUCT_VOL_VARS;

extern STRUCT_VOL_VARS vol_vars;


/////// for writting //////
EEPROMProgram((uint32_t *)(&(vol_vars.start)),E2P_LOCATION_FOR_VOL_VARS,sizeof(vol_vars) & 0xfffffffc);


////// for Reading  ////////
    if(sys_state.eeprom_error = (char)EEPROMInit())
    {
    	System_printf("EEPROM Init Error!!\n");
    }

    EEPROMRead((uint32_t *)(&(vol_vars.start)),E2P_LOCATION_FOR_VOL_VARS,sizeof(vol_vars));

Nimesh Modi said:

1. How much Time EEPROM write will take to write 100 Bytes data on fixed location?

If the 100 bytes constitute 25 words, then 25 x (110us to 600us). If the bytes are all in separate words, then 100 x ( 110us to 600us)

Nimesh Modi said:

2. In TM4C129ENCPDT controller data sheet it is mentioned "Program time for 32 bits of data with memory space available is Normally 110 us and Max 600 us" in that "space available" word used what it means? should we have to erase data before writing?

The EEPROM data is stored in blocks. There can be 7 copies of the data before a block must be erased before the 8th copy can be stored. This is done for you by the state machine but does increase the time significantly as you now must include the time to erase the block.

Nimesh Modi said:

3. Another line is "Program time for 32 bits of data in which a copy to the copy buffer is required, the copy buffer has space and less than 10% of EEPROM endurance used" in this "copy to copy buffer" means? Is it copying data from one EEPROM location to another?

Yes, basically, the data is programmed into a special "copy block", the original block is erased and then the data is programmed back into the original block. If the copy block is full at this time, it must be erased first which doubles the time required.

Back to your initial question. How long it takes to program 100 bytes of data depends on how the bytes are distributed among the 96 blocks. If multiple blocks must be erased, then the total time increases. Erase time increases with usage, that is why there are different values for in the first 10% and the last 90% of the EEPROM endurance.

Nimesh Modi said:

4. i am using "if(sys_state.eeprom_error = (char)EEPROMInit())" for validate EEPROM writing but it will give success always. any solution?

That is not the correct function to get the status of a programming operation. That function should be run immediately after the EEPROM module has been enabled to see if there was a power loss or reset while previously erasing a block.

The function to get the status of a programming operation is EEPROMStatusGet().

Nimesh Modi said:

we have custom design board. In our project we are saving data to EEPROM on power Fail Detection.

Even with fast external memory this is somewhat fragile and prone to failure. You need to protect against corruption not only to what you may be immediately writing but also to everything else in the EE.

Nimesh Modi said:

3. Another line is "Program time for 32 bits of data in which a copy to the copy buffer is required, the copy buffer has space and less than 10% of EEPROM endurance used" in this "copy to copy buffer" means? Is it copying data from one EEPROM location to another?

Note that this is still the most optimistic scenario. The pessimistic scenario is orders of magnitude longer.

Finally and this is very important. Read the errata thoroughly.

Robert

Bob Crosby said:

If the 100 bytes constitute 25 words, then 25 x (110us to 600us). If the bytes are all in separate words, then 100 x ( 110us to 600us)

Hi Bob,

Thanks for your Reply.

So EEPROM write should take 60ms max for 100 bytes. and we are able to produce 400 ms time after Power Fail detect. so what will be the reason of Writing is Failed. I already posted my code.

Thanks,
Nimesh

Nimesh Modi said:

So EEPROM write should take 60ms max for 100 bytes

I would actually measure that.

Nimesh Modi said:

and we are able to produce 400 ms time after Power Fail detect.

And also this.

Set an output bit on power fail detect.

Set an output bit (a different bit) when starting to write.

Clear that bit when the write is finished.

Use an oscilloscope or logic analyzer to measure all 4 points, requires 3 lines

• The power fail input
• The micro's power fail detect
• The start of the write
• The end of the write.

And do take a look at the worst case data sheet timing not just the best case as you are doing now.

Robert

Also the errata.

Robert Adsett said:

Even with fast external memory this is somewhat fragile and prone to failure. You need to protect against corruption not only to what you may be immediately writing but also to everything else in the EE.

Hi Robert,

Thanks For Reply.

Yes while testing i am also face the situation where i got garbage value and each of time that value is "21474836475".

Is there any other way to store data on power fail.

Nimesh

Hi Bruno,

Thanks for your suggestion.

It require changes in our custom board. i will try it.

Meanwhile can you look at my code. Is there anything wrong in it? 

Regards,

Nimesh

As others here have advised - your MCU, "Does not particularly "shine" (perform well) at such "Rapid Data-Saving role!"      (not "performing well" is a serious understatement...)

You persist in directing others to, "Look at your code" - even after you've been directed to "Non-MCU" means to better achieve your goal of,  "rapid & robust, fast data storage!"      You are aware of this fact - are you not?       While you have noted (some) agreement w/others here - such "code review" suggests that you are not yet "convinced."     (and this - even after you report (for the first time) your discovery of repeated - yet always - erroneous data!)      Pardon - but how does such, "Look at the code" make sense?

The fact that an MCU may "offer a function" - does not insure that "such function" is managed efficiently - or that it "competes reasonably" w/other - longer existing and superior (exterior device) means!

Sticking w/that "custom board" insures that there will be limitations placed upon (both) the amount of data you may save AND (more importantly) that data's robustness!       Can that - in any way - prove good?

Saving such data to a far faster, more robust, external (designed to task) device - would prove much to your advantage.       (And - if you've had the foresight to "bring out" the SPI bus - such may enable you to "keep" your board - adding just a small, external EEProm or possibly a Fram "plug-in board.")

Nimesh Modi said:

Is there any other way to store data on power fail.

Yes, use external memory. EEProm or FRAM. FRAM is by far the fastest. MRAM will match its speed but I haven't seen any designed for simple SPI or IIC connection.

However, and this is important, I would seriously question your need to save on power down. Particularly with FRAM you would save whenever a value changed. With EE you need to do some checks before attempting that but FRAM has essentially unlimited reads and writes. You still have your power fail but its purpose is to prevent writing if the power is about to fail so you run no chance of a write being interrupted by loss of power.

Robert

Re: "A KISS in disguise."       Disguise - here - may prove unnecessary - as the charge is - and remains - Full Speed ahead...

As you direct poster (away) from, "Saving on power down" - your direction (instead) to, "Save on key value change" requires "repetition & memorializing"  - as few here appear to, "honor/follow" such "wise practice!"       And the flawed Kitchen Sink's (MCU's struggled attempt) eeprom effort proves "disaster" (to be kind) in that critical regard...

Robert,
As usual, you observe from the tower, and slap me on the face with the obvious!
Why bother monitoring loss of power (using FRAM) when you can save data every time it changes?
Brilliant!
With FRAM, his system can even save the status every second, including a timestamp of "last time seen alive"...
Bruno

Coming to think of it, one of the first projects we made was a running time counter for an engine, based on low power MSP430... Of course, the whole purpose was to save the total system time "right when it got shut down"... At least a decade went by, but I can only say the techniques used back then were not elegant at all!

As fellow "Small Biz Owner" - might "elegance" reside w/in the "Paid bills eyes?" Returning regularly to a heated/lighted/unlocked work-space requires (some) achievement - which may - at times - wander into "elegance."

Bruno Saraiva said:

Robert,
As usual, you observe from the tower

There is "No doubt" of that - Robert IS to be regularly commended.

That said - after a bit of thought - "Might certain weakness - stain the cloth of Sainthood?"

If one, "Saves ONLY upon Change:"

• are you not vulnerable to "initial value selection & load?"     (assume initially "0" is loaded  - and all following data (severed cable) repeats "0"  - and is thus "Non-detectable!")
• and - should the (assumed) data Acquisition process become flawed, or locked, or somehow, "Not make it to the processing code responsible for such, "Change Detection" - what then?

I'm sure that Robert's thought of this - yet it appears that such, "Saving upon Change" demands (further/augmenting: tests & verifications) so that any such change has a, "Fair Chance" of being detected - then properly "passed thru/processed" - and finally (if/when valid - recorded!)

In addition - there IS value in detecting "last moment values" - especially if they can be "fully/properly" captured" - as they (alone) may provide the key "final data" - so often necessary during exceptional happenings ... usually unpleasant!

There is no universal solution, but to keep all as simple as possible, I would simply register the the FRAM saving function as a once-a-second periodic task, where the complete structure of relevant data would be CRC'd, mirrored and stored to memory, weather or not it changed.

If something could have changed on the last "half a second" and requires to be saved before a possible power failure, then a more specific "call saver upon change" will be required.

cb1_mobile said:

Bruno Saraiva

Robert,
As usual, you observe from the tower

There is "No doubt" of that - Robert IS to be regularly commended.

That said - after a bit of thought - "Might certain weakness - stain the cloth of Sainthood?"

If I am in a tower it stretches far above me. I can hear the voices of those toiling above.

cb1_mobile said:

are you not vulnerable to "initial value selection & load?"     (assume initially "0" is loaded  - and all following data (severed cable) repeats "0"  - and is thus "Non-detectable!")

And this would be a problem because ...? Either way zero is stored.

cb1_mobile said:

I'm sure that Robert's thought of this - yet it appears that such, "Saving upon Change" demands (further/augmenting: tests & verifications) so that any such change has a, "Fair Chance" of being detected - then properly "passed thru/processed" - and finally (if/when valid - recorded!)

Any communication based parameters will already have been validated before writing as parameters, so that should already have been taken care of.

Logging operating/failure conditions is a little different, but not hugely so. Conditions can be saved regularly (say every 10mS). Adding a change detect to this is an optimization not a part of it's basic operation as it would be for a parameter.

cb1_mobile said:

In addition - there IS value in detecting "last moment values"

There is, however, negative value in corrupting stored values. So detect exceptions and operation and write to storage but stop writing on power-down. Note you still require a hold-up to last the period of a write but your timing requirements change considerably thus simplifying the resulting SW. Note that on power down you should also be stopping the control since it can no longer be considered trustworthy.

There's really not a one size fits all here. My current approach is something like

• Fixed parameters
  • Defined via const (and maybe #define). No possibility to update at runtime
• Factory calibration and config. These are critical and must be preserved correctly. Since this only occurs once under controlled conditions even the TI EE would be acceptable here.
  • Stored in a block
  • Block is protected against undetected corruption by CRC
  • Block is mirrored with additional copy(ies) so if one block fails there is a backup
  • Default block in ROM for initial values and as an ultimate fall-back. Note this default set might disable all or part of the device if the loss of parameters is critical enough.
• User critical Config. Critical to operation, infrequently changed and must be preserved. Again if infrequently change and under controlled conditions the TI internal EE may be acceptable. This however must be considered.
  • Stored in a block
  • Block is protected against undetected corruption by CRC
  • Block is mirrored with additional copy(ies) so if one block fails there is a backup
  • Default block in ROM for initial values and as an ultimate fall-back
• User Non-critical Config. While important, reverting to default is not critical. This variation's biggest advantage over the critical config is the reduced storage space needed.
  • Stored in a block
  • Block is protected against undetected corruption by CRC
  • Default block in ROM for initial values and as a fall-back
• Operating and error logs. While you do not want errors, they are not critical. You may lose some diagnosis capabilities but operation remains unaffected if errors are undetected. Also these may need frequent and rapid updates so reducing the overhead is a significant advantage.
  • Stored in a block

This update frequently and stop writing on powerdown instead of only update on power-down approach does not really affect the final result in the NV storage. It is, though, simpler to write and easier to determine the power-fail conditions for. These two will result in a more robust solutions*. It does require that the NV storage potentially be able to survive more writes and more frequent writes.

Robert

* I do recall a hardware (IC) solution to that was supposed to update an EE on powerdown that had a failing batch. Had to add functional tests to verify that storage was successful and retained after a somewhat extended power off.

OP comes here asking someone to look at his code...
And he gets a complete article on microcontroller best practices!
Hope the value of this discussion and the excellent suggestions here are given due value!

Yet - it is expected - that (once more) poster will direct, "Look at my code!"
"Saving" the (likely) incompletely planned/implemented boards is & remains the "prime objective..."

Is it true that you've (not yet) received your, "Free Steak Coupon (via PM) from that joint in Madrid?"      (they've a special method for "accumulating" flavor elements around the ties...)

Hi,

The reason behind Asking "Look At My code" is we are using this logic for more than a year in different Project and we never face such issue in any project since we are able to produce 400ms Time after after power fail detect. another thing we already delivered our device to client. so it is not possible to use external "FRAM".  

but perhaps we should not trust internal EEPROM to store data on power failure condition in this controller. so it is just useless in our project.

for the time being i am happy to use "small backup battery". 

Thank you so much for your suggestions.

Nimesh 

That "small backup battery" may be challenged depending upon the, "Degree of such usage."     As you know - the "Write to eeprom function" draws heavily upon your power supply - and in your scenario - every power down (or possibly "brown out") will also - draw from the battery.

A battery management circuit (no mention of that) is usually required - so that the battery is employed (only) as & when needed.     So quick a "soltuion" - proves not always - the very best solution...

The inherent complexity & weakness of the "MCU's eeprom-lite" approach continues - "saved data robustness" may not be in "high evidence."

Nimesh Modi said:

The reason behind Asking "Look At My code" is we are using this logic for more than a year in different Project and we never face such issue in any project

So why key in on the code rather than the H/W?

Nimesh Modi said:

we are able to produce 400ms Time after after power fail detect.

Have you measured it? And then accounted for the lifetime degradation? Have you measure how long the EE write takes? Have you measured how long it takes to react to the power fail signal?

Given the data sheet figures, I would expect a small use worst case figure of more than 1/2 second write time. Long term worst case is far longer.

Nimesh Modi said:

another thing we already delivered our device to client. so it is not possible to use external "FRAM".  

Nimesh Modi said:

for the time being i am happy to use "small backup battery". 

These are contradictory statements. In either case modifications are required. Fairly substantial modifications are required for battery use, including some sort of shutdown circuit.

Robert

I agree that writing to non-volatile memory during power down is tricky, but what you are trying to do is fundamentally sound for the first 10% of the endurance (first 50K cycles). Under those circumstances you should be able to program 100 bytes in consecutive locations in well under 400mS. Bruno's suggestion to time events with output pins and a scope is a good one.

I have looked at your code, and that has made it somewhat difficult to give you specific answers. You asked about the maximum time to program 100 bytes, but your code shows programming 56 bytes of a structure that contains 57 bytes. The difference is significant because the EEPROM is broken into 64 byte blocks. If I program 56 bytes all within a single block, my maximum time is basically the small programming time and two erase times. (The extra erase is when the copy buffer must also be erased.) If the 56 bytes cross a block boundary, then the maximum time must include four erase times. Programming 100 bytes, must include five erase times if it crosses two page boundaries. Data alignment can affect the programming time.

I setup an experiment writing 56 bytes aligned within a single block. I measured the programming time on sequential writes.
cycles 1-6: 1.7mS
cycle 7: 16.3mS
cycles 8-13: 1.7mS
cycle 14: 16.3mS
cycles 15-20 1.7mS
cycle 21: 16.3mS
cycles 22-27: 1.7mS
cycle 28: 16.3mS
cycles 29-34: 1.7mS
cycle 35: 16.3mS
cycles 36-41: 1.7mS
cycle 42: 24.7mS

Notice the pattern, 6 cycles take 1.7mS, no erase is happening. The seventh cycle adds a single erase and takes 16.3mS. The sixth erase cycle takes an extra erase as the copy buffer is also erased.

My times may be slightly less than you measured since I only actually changed one 64-bit variable in the structure each time and this experiment was done at room temperature. Changing more variables will increase the programming time, but the erase time will be the same. The erase time does increase with cycling and low temperature, but usually not until well into the endurance life of the flash memory.

In short, if you are not able to program 100 bytes of EEPROM on a relatively new part in under 400mS, something else is wrong and should be investigated.

Bob,

Most excellent - firm/I "wrapping up" - yet one saw your work - we had to say, "Bravo." (when 20-somethings "appreciate" your work - that IS something!)

The combination of the detail - the deep explanation - (almost) makes me want to employ the "MCU's Flash as EEProm." (what holds me back is the (known) "comparison" between these results - and those obtained w/a "real" EEProm (designed to purpose...)

Good application aiding and inspiring job - nonetheless...