-->
Page 1 of 2

Saving application state between boots ...

PostPosted: Wed Oct 21, 2015 10:33 pm
by kolban
Imagine I write an app for an ESP8266. I understand that I can write to flash memory and save data there and then re-load it on next startup. This would allow me to save configuration state and data.

My question is ... is there an area of flash address space which has been pre-allocated as a "safe" place for applications to store data? Perhaps some where in the address space that is "reserved" for this purpose? Let us assume that only one application will ever run on the device.

Re: Saving application state between boots ...

PostPosted: Wed Oct 21, 2015 11:14 pm
by Mmiscool
When using the arduino environment for esp the flash memory is broken up s shown below.

Code: Select all|--------------|-------|---------------|--|--|--|--|--|
^              ^       ^               ^     ^
Sketch    OTA update   File system   EEPROM  WiFi config (SDK)


Flash for the spiffs file system remains after each re flash of the sketch. There is also the simulated eprom space for comparability with some existing arduino sketches. Don't know if this is the answer you are looking for.

Re: Saving application state between boots ...

PostPosted: Thu Oct 22, 2015 12:03 am
by kolban
Thanks for the response. I'm not specifically looking for an Android or Lua or Basic story ... rather I am wondering if there is a general story for the ESP8266 itself when coding directly to the SDK. It seems to me that if I write an app, I know how big that app is ... and then I can use the memory north of that in flash to read and write from. However, this assumes that I know the maximum size of the app I am writing. Rather I am wondering if there isn't some area of flash memory that is architected for storing app specific information.

Re: Saving application state between boots ...

PostPosted: Thu Oct 22, 2015 9:39 am
by dkinzer
kolban wrote:Rather I am wondering if there isn't some area of flash memory that is architected for storing app specific information.
There isn't. Assuming you're not using OTA, you can use the space from address 0 in Flash all the way up to the system parameter area (16K from the end of Flash) however you'd like.

If you want to reserve a 4K block immediately preceding the system parameter area for your app's non-volatile data you can do that. You'll have to keep an eye on the size of you app to make sure it doesn't overlap your "reserved" block *or* you can modify the linker script to reflect the smaller size.

In the linker script you'll find a section like this:
Code: Select allMEMORY
{
  dport0_0_seg :  org = 0x3FF00000, len = 0x10
  dram0_0_seg :   org = 0x3FFE8000, len = 0x14000
  iram1_0_seg :   org = 0x40100000, len = 0x8000
  irom0_0_seg :   org = 0x40240000, len = 0x3C000
}

The irom0_0_seg line is the important one for this discussion. The line shown gives the address of the irom0 section and its length. The org parameter gives starting address in terms of the Flash chip as it is mapped into the esp8266 address space where address 0 of the Flash chip is 0x40200000 of the address space. You can see, then, that the irom0 section begins at 0x40000 and its length is given as 0x3c000, nestling right up to the system parameter area at 0x7c000 (this is for a 512KB Flash chip).

You can reserve 4K of Flash by simply changing the length if the irom0 section to 0x3b000. Note, however, that there really isn't any good reason for irom0 to begin at 0x40000. Any address after 64KB is fine so you could set the beginning of irom0 to 0x10000 and make its length 0x6b000 leaving 4K free preceding the system parameter area.

If you make a change to the start of irom0 like this you'll have to remember to modify the parameters accordingly when you download the app to the chip.