[INFO] Flash Driver model

[Giovanni]

Hi,

Just a note, I am working on a NOR flash driver (step 1) model and a test implementation on Micron N25Q128 128Mb flash over SPI. If you have comments please post here. The driver is under ./os/ex/Micron, the generic interface is under ./os/hal/lib/peripherals/flash/hal_flash.h

The successive steps will be:

2) A "Managed Flash Storage" module, basically an EEPROM emulator where you can read/write/erase blocks identified by a number. It will handle EE-emulation, wear leveling, garbage collection and state recovery after power failure.
3) A block device emulator on top of MFS implementing a BaseBlockDevice interface, it will allow the use of FatFS or other block-oriented file systems on top of NOR flash.
4) (TBD) a native Flash FS on top of MFS.

Giovanni

[electronic_eel]

Interesting. I'll be needing something like this in one of my next projects.

2) A "Managed Flash Storage" module, basically an EEPROM emulator where you can read/write/erase blocks identified by a number. It will handle EE-emulation, wear leveling, garbage collection and state recovery after power failure.

Do you really need wear leveling on a NOR flash? Probably if you are expecting a big number of writes, but usually not if you are just storing firmware, configuration and mostly static data.

Will there be a feature-reduced version of this driver available?

My planned application is a bootloader thing. You upload new firmware with the regular system via TCP/IP, it stored in the SPI flash, checksummed, reset and then the bootloader transfers it into the controller flash. If it fails there is another failsafe firmware version also stored in the SPI flash. So I need to split the flash into different chunks.

So I'm mostly concerned about a rock solid binary structure stored on the flash (I will never be able to fix it later), code size, bugs in the manager code and easy analyzation of the flash contents.

I guess this will be easier if you add one even more basic layer on the bottom which just provides access to numbered blocks of data and some block allocation and ordering map. On top of that you could build the wear leveling, garbage collection and state recovery. This would make it even more modular.

[Giovanni]

Hi,

There is a little misunderstanding I think. The driver does not perform wear leveling or anything, it just presents a low level API: read, program, erase.

It is the MFS module that performs wear leveling and so on. If you need just static storage then the flash driver is sufficient.

Giovanni

[electronic_eel]

Thanks for your answer. I think my wording was not precise enough, my use of "driver" was confusing and I meant the "Managed Flash Storage" module. Sorry for that.

But I thought some more about this. Using the bare flash driver and the raw sectors on the flash ic will probably the best solution for the bootloader.

But I also want to be able to use parts of the flash for other stuff like configuration or webserver content. So it would be nice if you could split the available flash memory on sector boundaries:

E.g. your N25Q128 has 256 sectors of 64KByte each. For the two firmware blocks of the bootloader I need e.g. sector 0 to 31 which I would access directly through the flash driver.

Then it would be nice if I could tell the "Managed Flash Storage" module to use only sectors 32 to 255 and present that to the file system layers above.

[Giovanni]

Hi,

That is exactly the idea, you assign some sectors to a MFS instance, the rest is not touched.

Giovanni

[Giovanni]

Hi,

Update, the flash driver for N25Q128A devices now works, it can be used as template for new drivers.

A simple demo is available under /testhal/STM32/STM32F3xx/SPI-N25Q128

Feedback is welcome, the driver model is not frozen yet.

Giovanni

[Giovanni]

Modified the driver:

1) Erase operation are potentially very long so the API is no more blocking. The erase operation is started and the function returns immediately.
2) Added functions flashQueryErase() and flashWaitErase() to poll/wait for erase completion.
3) Other functions when called while an erase is in progress return FLASH_BUSY_ERASE.
4) A suspend mode is planned but not yet implemented. When it will be active functions will be able to suspend an erase, perform the operation and then resume the erase. Most chips have HW support for this.

I think the driver model is reasonably complete now.

Giovanni

[neums]

Hi,
maybe a function like get_status is useful to verify the connection status. This can be done by trying to read the chip's identification via 0x9E command.

[electronic_eel]

Thanks for implementing this so fast. I have browsed over the hal interface, but didn't try out the code because I don't have a N25Q128 at hand.

I suggest to add a function to get the actual JEDEC flash id with manufacturer id, device id and size. Think changing the flash model between manufacturing runs and the firmware should be common to all models. The code could then select the right hal driver for the hardware present.

Most of the better specced flash models also offer a manufacturer programmed and non-writable uid. Wouldn't it make sense to add a function to the flash-hal to read that out? The size of the uid varies between manufacturers and some don't offer this feature. So the interface should include a function to get the size of the uid (which can be 0 if not existing).

I also tried to think of a common model of write protection schemes between the flash models I'm familiar with. But this is an area where the different manufacturers each offer their own scheme and although the features are similar, it is hard to provide a common interface. So I would not include that in the hal interface for now.

[Giovanni]

Hi,

The BaseFlash class is generic, not just meant for SPI devices but also memory mapped flash or other types, the "get id" thing is very specific of the SPI type I think. Perhaps a sub class should be created for all JEDEC types connected over SPI and add there the extra methods (and an API to send direct commands, all problems solved).

I am thinking to modify the N25Q128 driver to accept all sizes of that family by reading the ID and building the descriptor (note it is not const) but I am not sure it would be possible to make a generic driver for multiple families, is there a standard for the minimum features set?

BTW, I am working on a QSPI driver while I am at it, it is becoming a standard feature nowadays.

Giovanni