Example for writing flash

[faulesocke]

In #257 flash write support was added. However, no example and only little documentation was provided on how to use it. Would it be possible that someone writes an example that reads/writes flash and maybe elaborates on the following topics:

• how to find out which flash pages are unused by code and can therefore be used for arbitrary reads/writes
• handling firmware updates: when configuration data is stored in flash, how can one assure that it doesn't get overwritten during the next firmware update?

[Windfisch]

Hi @faulesocke,

while I don't have the time to write such an example right now, I can try to quickly answer your questions. Maybe you can make an example or update the documentation from this :).

You don't find out what flash areas are unused, but you actively specify that to the linker. Each embedded project has this memory.x file lying around with these contents:

/* STM32F103C8T6 */
MEMORY
{
    FLASH : ORIGIN = 0x08000000, LENGTH = 64K
    RAM   : ORIGIN = 0x20000000, LENGTH = 20K
}

This file specifies where the linker may put code and where it may put variables. In this case, it specifies that the flash area that can be used for program code starts at 0x8000000 and has a length of 64KiB (that is 65536 bytes). By changing this to 60K, for example, you force the linker to leave the last 4 KiB of flash unused. This means that you can happily use that area for storing configuration data or similar.

Note that this only instructs the language toolchain to not use that memory. It will not instruct your flashing tool to actually not overwrite that area.

For firmware updates, it depends on your flashing tool. If you use stm32flash, you must specify the -e option: -e n Only erase n pages before writing the flash. E.g., that would be stm32flash -e 60 on a device with 1KiB flash pages. If you use a bootloader, it depends on the bootloader. I use sboot together with dfu-util on the PC side, and it appears that no options are needed for it to not overwrite the unused memory region.

(Also note that the flash module currently has a bug causing verification for erase to fail, see #362. To work around this, use writer.change_verification(false) before calling .erase(), then turn it back on for the actual .write() again. This is fixed in master)