Writing to the onboard Flash

I’ve looked through the “Beginners guide to NETMF” PDF and the forum, but could find any information on whether or not writing to the onboard flash is possible.

For example, I have a Panda and I’d like to store some settings to flash, so when I power it off and then on again, my settings can be retrieved.

I only have a few settings to save, so using an SD card would be overkill.

EDIT: Woops, didn’t see the bit about the Panda. EWR is only on the Cobra.

Just to note, the Arduino has the ability to write to EEPROM, does the Panda EEPROM?

I would also like Gus to maybe explain further if possible. I assume it has to do with no external flash on the non-EMX models. Why they can’t write to flash inside usbizi, I do not know. Maybe has to do with needing to allocate a block for this purpose (cobra allocates external 256k for EWR for example).

I would think a simple compromise could be had if MS implemented. Let the developer decide. You could allocate Properties.Resource byte array(s) during dev. The resource file would be deployed and have the allocated array(s) in the resource area of flash. Then allow dev to read/write to those fields and use any way he/she wants (just can’t overflow array). In this way, they don’t have to reserve custom space. It is already researved by virtue of the resource file usage. They could probably also allow using Properties same as window app uses today, but with flash. Except you would define a max block size ahead of time, and get runtime error if saving properties would run over the block. Some kind of solution here I think. That amount of mem is then just part of the App deploy footprint.

I would think that this all depends on the erase block size inside the CPU. If it is too large then some info would have to be cached to ram, erace block, rewrite whole block with the changed data together with the unchanged data.

But what would happen if power is lost after erase but before write?

I would hang an EEPROM off the I2C bus for storing settings…

Why not use the battery backed RAM you have 2k and only needs a battery…

The idea is simple, if you run out of program flash then you can add external flash but if you need eeprom then you can add an external eeprom; therefore, the entire flash was allocated for program deployment and none for storage.

Now, after having USBizi out for so long and not seeing that the flash is large enough for every application so far, it may not be a bad idea to reserve few KB for storage.

I will run this by the right people at GHI and see if this can be added in next release

Thanks for all the replies - all very good suggestions.
I’ve just bought 2 24LC256 (256kBit) - It should be a fun exercise to use it.

Battery Backed RAM - Doesn’t this get lost after resetting the board?

Gus: I’m all for freeing up a few extra KBs for storage purposes.

Hi. Sorry to bump such an old post, but was this ever added to USBizi? I have a board from our hardware department using the chip and I’d like to store a serial number that you can set at runtime.

Will I need to get them to add an EEPROM?


Yes it is added, actually more than one option!




Two very nice Classes added by GHI.

If you are only storing a serial number, then PermanentUserKey would be the one you are after, but the only downside/upside (depends on how you look at it) is that you can only write to it once. BTW it is only 16 bytes, so it you are using a GUID you’ll just be able to sneak it in. (128bits = GUID = 16 bytes) I’d say that’s why GHI picked the number.

I’m trying to do this as well. I have the Fez Corba which has 4.5MB of flash. Tried using that InternalFlashStorage to read the size of it or try to write some data there. Its just gives me an

An unhandled exception of type ‘System.InvalidOperationException’ occurred in GHIElectronics.NETMF.Hardware.dll

That was trying to do something like:


Is it possible to write to this flash to store configuration files or do I need external storage like SD to store system configuration.


Please take a second look at the methods mentioned above.