Saving Data Across Reboot Without External Storage

Sorry if this is very basic but …

I have been away from NETMF for a while but back in my FEZ Panda and ChipworksX days you could save some small amount of data to battery backed up RAM or flash without an external Flash or SD card.

Now I am using Gadgeteer and a Raptor and for the life of me I can’t find if it is possible, and if so, how. Certainly the old approach does not work. I’d rather not use an SD card if it can be avoided since users can make off with those :frowning:

Can anybody point me in the right direction.


That was the letdown of the G400 and I need to consider adding a battery backed RAM to any new designs. Something I2C or SPI would be ideal.

It’s great for storing constantly updating data that needs to persist across reboots. Flash would not stand up to the constant writing.

That is what I guessed.

There is obviously some mechanism since FezConfig can store LCD and network data, but I guess there is no user access to the mechanism.

Thanks for the reply. SD card here I come!

@ Duncan - Have you considered to use ExtendedWeakReference?

The LCD data is stored in the FLASH and I believe the same for the ExtendedWeakReference.

The issue for me is that data can be changing every few seconds (example, flow sensor pulse accumulation) and I need to store these so that in the event there is a power failure and on restart I can read the last known data and continue from there. I may have lost a little but as the power has failed I can assume the pump has stopped too, if I am not controlling it.

FLASH is not ideal for this type of continuous update and battery back RAM is ideal. The ChipworkX had a small amount that worked great for this. The CPU on the G400 does not appear to have this capability, or at least not exposed to NETMF calls.

@ Robvan: That is how I did it on the older boards. But I can`t find it on the Raptor. If it is possible, please point me in the right direction cause I am lost in the woods and can’t find the way.

@ Dave: I have also faced the problem of often written data that needs to be saved for a crash. We once wrote a convoluted system that wrote a different spot on the flash every cycle, and another time we had a power supply that lasted long enough after brownout that we could write the data before the processor went down. In this case my needs are simpler; I just want to save a few parameters over a power cycle that are fairly static but I don’t want the user to be able to make off with them on an SD Card.

EWR is part of NETMF. The only Thing GHI adds to this is a flush fucntion.
It should be available for all boards.
The touch configuration is usually stored with EWR for example.

So hang on you want to be able to store data in memory that persists between reboots or power cycles? If you’re never turning off the power and the CPU isn’t flushing the RAM automatically on start up then won’t the data be there when you reboot?

EDIT: Or did I just put my foot in my mouth and that’s what extended weak reference is?

In fact you are not toptaly wrong.

I saw this on my MedusaMini (Arduino).
The RAM data stayed on a normal reset (without power off).
Bit in NETMF every new variable is initialized with the default value on creation.
Because of the Memory manager it’s also impossible to know if the variable you create has the same physical memory address as before.
It can even move around in memory over time (the GC defragments the memory).
Since you have no real pointers in .net (and NETMF) you can not just access any address.

Perhaps when the device initializes you can have as the first statement be a static data block. Where the framework always knows where that data is and knows not to overwrite it. In this data block you can write/read any values you like.

In theory yes, but since .net(mf) always initializes the fields and properties with default values (which is a good thing normally) it will not work.
And even if it’s static, I would not bet on it to remain at the same memory location over a longer period. Not sure if the NETMF GC currently moves date to defragment the RAM, but it might do so in the future.
If the static var is moved in memory, then your data is lost, when it gets created at next reboot at the old location.
EWR or Flash is the way to go here.
And the new docs say there is Memory buffered RAM on G120 (5x4 Byte).
Not sure if this exists for G400.