Mbed-os: FlashIAP not a BlockDevice

[drahnr]

• Type: Bug / Enhancement
• Priority: Minor

Enhancement

Reason to enhance or problem with existing solution
Convenience, otherwise people requiring this will implement a (99%) opaque wrapper around the FlashAPI.

Suggested enhancement
Derive FlashIAP from BlockDevice

Pros
Parts of the internal Flash can be used as user config storage very easily with the SlicingBlockDevice API and LittleFileSystem/FATFileSystem.

Cons
Risk of unaware people of the necessity of an offset for the program itself might overwrite the actual application.

[cmonr]

@geky?

[0xc0170]

FlashIAP is a driver, it can be used to built on top of it filesystemlike device or similar. However, should this driver be exposed as blockdevice? I fear your cons (a reason why it should not), that FlashIAP should not be exposed that way , not even used for that purpose - I believe the good choice here would be to have QSPI flash or similar

[drahnr]

If this is not deemed viable, I assume this can be closed.

[0xc0170]

Having said that, I forgot to ask for the use case - how are you using FlashIAP (what type of storage, when and how).

[drahnr]

Use case is legacy devices which do not have the option to add external flash but still have enough internal for a small user config fs which is more a of paramter one time read on boot. This allows us to roll out new firmware on older hardware.

[geky]

Hi, sorry for the late response.

We do actually have an expiremental wrapper for FlashIAP->BlockDevice outside of tree:
https://github.com/ARMmbed/flashiap-driver

It's been used successfully in several projects.

---

Integrating FlashIAP into the BlockDevice heirarchy has come up several times before, but there have been several concerns that have kept this from happening:

• FlashIAP has variable sector sizes, and these are often very intentional sizes. Consider the flash layout for the NUCLEO_F429ZI:
  

This doesn't fit well with the fixed-sized blocks of block devices, which most filesystems are designed around.

• Internal flash usually has a unit of magnitude fewer erase cycles compared to external flash, 10K vs 100K. Limiting writes is more important on internal flash.

• Writing to internal flash disables interrupts and freezes the device for an amount of time. On K64F this is 113 ms. In this time no IRQs will trigger, potentially disruptioning tasks with timing requirements, such as network stacks or watchdogs.

Because of these, using FlashIAP needs to be very intentional and thought out. For general purpose storage external flash is prefered, and @dannybenor's team has been working on storage API's specific to internal flash (https://github.com/ARMmbed/mbed-os/pull/5900).

Because of this mbed-os has been too scared to merge FlashIAP into the block device heirarchy for a while now. But I think the FlashIAP -> BlockDevice wrapper is an acceptable solution to this situation. It still allows you to manually put FlashIAP in the BlockDevice heirarchy, such as for the use case you mentioned, but the extra layer of indirection gives the hint that this solution may not be the best one.

cc @davidsaada, @c1728p9, feel free to add anything I missed

[drahnr]

@geky I ended up doing exactly that - wrapping FlashIAP (again), not knowing of the previous work. Stumbled upon the same issues regarding varying sector/page sizes, but it is not an issue in my case, so I am all good and this can stay closed from my point of view.