Hi!
I have a Nordic NRF52840 development kit and am trying to interface with the MX25R6435F flash chip. It communicates over QSPI, so I know I have to go through the QSPI driver to use it effectively and read/write from it. I'm trying to write an API for basic IO operations (read/write), with basic error-handling baked in. Essentially just a middle layer between the Driver and the App to provide some nicer features. However, I don't want to reinvent the wheel if something like this has already been thought of in the SDK. For example, I really like the features provided by the Flash Data Storage library, such as:
- Minimizing flash operations
- CRC verification
- Basic wear leveling
- etc.
The SDK documentation states that this library calls upon the Flash Storage library to actually access the filesystem/memory... but I don't see where this is configured to actually interface with the hardware (I guess it talks to some other flash chip on the dev board?).
Anyways, I was wondering if there was a way to use the QSPI driver + MX25R6435F provided on the dev board as a backend to Flash Data Storage.
I see an interesting Common Library named "Block Device" in the SDK, which states the following:
This module implements unified block device API. It could used as a middle layer between filesystems and memories.
And there is indeed a QSPI implementation for this Block Device feature - but I'm confused as to how it's possible to interface the FDS filesystem with QSPI-accessible memory using it. Is this even its intended use? The only example of the Block Device being used with QSPI is in the "USB MSC Example".
I'd love to get a little bit of your advice and guidance as to how I should implement a nice "file layer" between the QSPI flash chip and my App.
Cheers!
