[flash] Add simple STM32 Flash driver

[salkinium]

This is a low-level driver that only implements the erasing and programming in RAM code.

TODO:

• Implemented and tested on G0.
• Implemented and tested on L0. We don't have L0 support yet, oops.
• Implemented and tested on F4.

[salkinium]

Speed is very interesting:

• On STM32G0 you can erase with ~2114kiB/s, but only program with ~94kiB/s.

   Erasing sectors [32, 64)
   Erasing done in 31815us with errors: 0
   Erasing with 2114kiB/s
   Programming done in 709179us with errors: 0
   Programming with 94kiB/s
  

• On STM32F4 you can erase with only ~168KiB/s, but program with ~1497 KiB/s.

   Erasing sectors [6, 8)
   Erasing done in 1591412us with errors: 0
   Erasing with 168kiB/s
   Programming done in 179649us with errors: 0
   Programming with 1497kiB/s
  

[rleh]

Is there a reason why this does not implement the modm::BlockDevice interface?

[salkinium]

Is there a reason why this does not implement the modm::BlockDevice interface?

Maybe later. I first want to gather support for a few more families to understand what the limitations are on this.
It's not trivial to implement a byte access protocol on something that can only program uint64_t for example.

[salkinium]

My use-case it a IAP firmware update, and not a non-volatile data storage. I'm fairly certain a file system requires more a little more integration than this.

[rleh]

The modm::BlockDevice interface exposes the read/write/erase block sizes to the layer above (to the user), that's the point.

[rleh]

My use-case it a IAP firmware update

Why should this not work (and result in portable code) with the modm::BlockDevice interface?

What is the difference between a non-volatile firmware storage and a non-volatile data storage?

[salkinium]

Maybe later. I'm not sure if implementing a block device for the internal Flash is that useful. There should be an adapter, that provides a linkerscript-assisted range, so that there's no chance to erase/overwrite your own firmware.

There's also additional limitations on write-while-read (the flash bus stalls, so everything halts during erase/program, except for code/data placed in RAM hence modm_ramcode).
Additionally, the blocks are not fixed size, F4 has 4x 16kB, 1x 64kB and up to 7x 128kB, repeated again for devices with 2 banks, and in addition the word length is not fixed (8, 16 or 32-bit).

It's also not clear how to do proper read-modify-write, without using an unreasonable amount of (temporary) RAM. Typically these are implemented as some form of write-only model, where new data is programmed into only erased data, which required non-steady data addresses, etc.
I doubt Block Device exposes enough information to implement that.