How to read and write content on Flash in the bytes level addressing

Hi folks,

I am currently using Particle photon to do some IoT project. Based on the documentation, The EEPROM class provides several useful API for reading and writing data to EEPROM. However, it seems the addressing of EEPROM is different to physical flash. (I guess this is why it is called emulated EEPROM).

Here are some interesting experiments I have done:
Experiment 1: use dfu-util to dig out content in the flash using:
sudo dfu-util -a 1 -s 0x9a4:1024 -U newfile.bin

By hexdump-ing the newfile.bin, there are some interesting things showing up:
00000000: 6465 7669 6365 2e73 7061 726b 2e69 6f00 device.spark.io.
00000010: ffff ffff ffff ffff ffff ffff ffff ffff …
<…>

It shows how the hostname stored in the flash physically…

Experiment 2: try to find host name in application level:
I tried my best to find out the hostname on application level using provided EEPROM and spark-flashee-eeprom by @mdma. However all data digged out is 0xff, i.e. empty.

I am wondering whether there are any possibilities to access (read and write) data on the flash directly, i.e. write/read data on a specified address of flash?

I have tried the way that is proposed by @bko on here using similar function:
sFLASH_ReadBuffer(byteBuffer, FLASHADDR, 256);

However, it turns out the compiler cannot find this function definition. Should I include anything in the project?

Thank you!

Hi @chenc

The EEPROM is emulated in Flash memory. What that means practically speaking is the any particular sector of data is not always at the same location. Since you can only erase an entire sector, to add or change data to the EEPROM, the system copies the old data to a new sector and then add the new data. It is then safe for it to erase the entire old sector. The system keeps a map of good sectors so it can find everything. The system also spreads data around doing what is called “wear-leveling” since reading and writing one sector over and over again can prematurely wear it out.

You can’t find that function because you don’t need it anymore. It was part of the early efforts at emulation on the Spark Core, the older product that is not available anymore. You should use what is provided in the system firmware EEPROM class doc’ed here:

https://docs.particle.io/reference/firmware/photon/#eeprom

Finally, it is not clear what you are trying to achieve. If you are just learning that is great but if you have some goal in mind, I could not figure out what it was. So please ask a more direct question about what you are trying to do if you want help.

1 Like

Thanks for your message!

I am thinking how to store/overwrite data directly on the flash by specifying a particular address. This address on the flash should be a contiguous block similar to the hostname or Public/Private Key. The simple experiment I am trying to do is to read the contents (like Public/Private Key/Hostname) from the flash from the application level program. Is it possible to do it?

When writing to flash, you can only store 0 bits. Once a bit is set to 0 you can’t set it back to 1 except by erasing the entire flash sector, which ranges from 16 KBytes to 128 Kbytes, depending on which of the 16 sectors on the STM32F205 you are writing to.

The DCT values for the server key, etc. have two sectors, and whenever you make a change the entire DCT has to be copied into the other sector and the old sector erased, because you can’t set bits back to 1.

The EEPROM emulation does this more cleverly, so you can make a bunch of writes before having to erase the sector.

In any case, you don’t need anything special to read the flash memory sectors - they’re directly accessible the same way RAM is. You just make a pointer to the actual location in the memory map.

Writing, however, is much more difficult.

3 Likes

By the way, using dfu-util with the -a 1 option does an automatic mapping to the current DCT sector.

If you want to find out the actual memory address for a DCT value, the formula is in this document:

4 Likes

Thanks for this great doc and post!