Brownout detection

[rayE]

Hi All,
Please correct me if im wrong on this, but an 8266 module has NO non volatile RAM? rather you can write to the RTC memory or general purpose flash memory?

What i want to do is log the RTC time when there is a power failure and log the time when the power was restored. To accomplish this im thinking on using the following method.

1. I have a BOD circuit (brown out detection) that feeds a D/I pin on the ESP8266 module (maybe an interrupt).
2. I have a small super cap that is charged from 5V and feeds the I/P to a 3V3 regulator that powers the ESP module.
3. If the 5V I/P to the regulator fails (brownout) then the super cap powers the ESP module for a couple of seconds.
4. I turn off the WiFi on BOD (to conserve power) OR put the module into a light sleep?, and write a time stamp to flash memory OR RTC memory.
5. Put the module into deep sleep.
6. Once the power i back i write the BOD time stamp AND the power normal time stamp to IOT database, this will then log BOD.

Any thoughts on this is appreciated.

TIA
Ray

[TD-er]

Instead of such an elaborate setup, wouldn't it be easier to have support for I2C FRAM, which could act as RTC, but then keeping the values when power is lost.

You can also run a script at boot, where you can detect the last boot cause (not sure if that's already present in the code as a system variable) and if it is a cold boot, then you know the device was without power (or the reset was intentional pressed)

[rayE]

No its extra expense, reduced cost of the end product is essential.

[rayE]

Does the last boot cause have a timestamp?

[rayE]

Actually, and more important, how is the last boot cause stored?

[TD-er]

Actually, and more important, how is the last boot cause stored?

If not initialized, then it was a cold boot.
Otherwise it will store the last boot cause in RTC. (a single byte)

We can read it, but I can add a system variable for it to be able to use it in rules, which can be useful for a lot of other use cases too.
The timestamp is not kept anywhere if the power is lost.
And writing to flash in case of an "emergency" may be a nice feature, but I'm afraid we may corrupt things if the power left for saving is just not enough.
There is an EPROM section in the flash, which we do not yet use and I was thinking of using it for special purposes like OTA definitions etc.
It could be used also for these kind of things, but not sure how to structure such an emergency shutdown procedure.
Should it be a plugin (it has to use a GPIO pin)?

[rayE]

There is an EPROM section in the flash, which we do not yet use and I was thinking of using it for special purposes like OTA definitions etc.

Now THAT would be a real sexy/useful feature to have, i take it this is NON volatile? how many bytes are available? AND as you say a method of keeping the module alive is required, although this is a relatively simple implementation in HW using a super cap, a diode and a resistor, should keep things moving for a few seconds, enough time to write to EPROM?

[TD-er]

It is non-volatile, since it is part of the flash layout.
Not sure of the size, but a few kByte I guess.
The erase size for flash is about 4k, so I guess it is something like that.
Also the EPROM part does not have a specific structure, so we can do what we like with it. (as far as I know)

[rayE]

This really does sound pretty cool. I have seen lots of posts regarding "states" after a reboot...................problem solved?

[rayE]

Simple HW implementation...............The AT tiny dotted stuff is the 3V3 regualator if using a ESP module without a regulator.

attachment=0]download.jpg[/attachment]

Loose the LED, wasted power. Also from the data sheet the flash memory has a write limitation of 10K, after this that part of flash can become "worn"!

[TD-er]

This really does sound pretty cool. I have seen lots of posts regarding "states" after a reboot...................problem solved?

Not really, the values will only be saved when the emergency exit procedure can be executed.
That won't be when the unit crashes.
So that's why I still would like to implement the FRAM idea I have in mind, since that can be written in the order of 10^14 times (or more) and quite fast also.
Those FRAM chips can be had in sizes of a few kB to 256 kB (or even more?), although they are rather expensive per kB storage.
But they do add a lot of flexibility.

[rayE]

Understood, iv used FRAM many years back on a PIC application. Cheaper today BUT overkill for my application, If it's just a few bytes you need to store once in a while on a certain trigger.

[rayE]

I should have added, the simple circuit i attached will also have a BOD before the diode and attached to a D/I pin on the esp through a potential divider. This will alert the ESP that the main supply has gone down and to enter emergency save to flash mode.

In my location we have a brown out once a day that lasts for maybe 2 hours max, so if the ESP can enter deep sleep after the write to flash, and stay alive for a few hours on the super cap in sleep mode (~200uA) then all is well. Ill give it a try and report back.

10,000 writes to flash/365 (once a day write) = 27.3 years of usage more than enough without extra HW

[rayE]

Is writing to very top of Flash safe? so if i have 4M, 1M spiffs where would i write to safely? Or i just write to a dummy var?

[TD-er]

It is not yet implemented.
But the area for EPROM section is already present on the flash.
See here for the flash layout.

[rayE]

Thanks TD-r. Ill report back on this with my chosen solution, it could be handy for others.