Flash NAND supported by block device

[joel-sc]

Hello,

Before going into detail, the question is: Is there is any chance that NAND flash will be supported (via QSPI or SPI) by the nRF5 sdk in the future ?

My question is concerning usb mass storage and fatfs use cases where the block device library provides several backends supporting memory types.

It seems current backend supported by the block device library in the nRF5 sdk (17.0.2) is the following:

• In RAM
• Empty
• QSPI (only available for NOR flash)
• SDCARD

The two current issues if I'm correct, are; the QSPI peripheral is only supporting NOR flash and there is no backend specific to NAND flash.

Since there is a lot of threads in the Devzone asking for NAND flash support, I'm wonder if Nordic will support it. SO what is the current status about it ?

Another question: Which FTL algorithm is used in the qspi block device ? Does it support wear leveling ?

Best

Joël

[JONATHAN LL]

Hello

Is there is any chance that NAND flash will be supported (via QSPI or SPI) by the nRF5 sdk in the future ?

There is currently not plan to support NAND over QSPI any time soon, but using SPI you should be able to use NAND. 


See:
nRF52840 + External SPI NAND FLASH + FATFS - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) 
Alternatively there are some chips that might be compatible like this https://www.macronix.com/Lists/Datasheet/Attachments/7830/MX35LF4G24AD,%203V,%204Gb,%20v1.0.pdf#page=29 as a example. 
Here is another case that might help with alterative solution: Supported NAND flash for QSPI and fatFS - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) 

Which FTL algorithm is used in the qspi block device ? Does it support wear leveling ?

 Will have to get back to you on this

Regards,
Jonathan

[joel-sc]

Hi!

JONATHAN LL said:

but using SPI you should be able to use NAND. 

That mean we need a SPI NAND block device (including a Flash Translation Layer). Is it in the nRF5 SDK roadmap ?

JONATHAN LL said:

See:
nRF52840 + External SPI NAND FLASH + FATFS - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) 
Alternatively there are some chips that might be compatible like this https://www.macronix.com/Lists/Datasheet/Attachments/7830/MX35LF4G24AD,%203V,%204Gb,%20v1.0.pdf#page=29 as a example. 
Here is another case that might help with alterative solution: Supported NAND flash for QSPI and fatFS - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) 

Thanks for you suggestion and your time, I'll check it.

Best,

[JONATHAN LL]

Hi,

joel-sc said:

That mean we need a SPI NAND block device (including a Flash Translation Layer). Is it in the nRF5 SDK roadmap ?

Sorry for being so inconclusive in the answer, there is no solution for NAND in the nrf5 SDK. You could implement your own solution for SPI and NAND, it is technically possible to write the block device yourself. Using SPI in nRF Connect SDK (NCS) as i linked to in the first link was what i was referring to but i was unclear, so sorry about that. 


As for the algorithm i could not confirm a a name/type but it does not support wear leveling. However littlefs can be used in NCS and it does support wear leveling. 

Regards,
Jonathan

[joel-sc]

Hi!

Don't be sorry, I appreciate your time and help !

The first link you gave advice going toward nRF Connect SDK and use LittleFS as it support wear leveling and bad block management. However LittleFS is not officially supported by commercial OS (like Windows). Our clients should be able to upload/download files to the mounted USB device, and thus will need a third party software (like LiffleFS Explorer for Windows [1]), and we do not want to install third party software on the host machine. Additionally we didn't plan to migrate on NCS for now.

I think I will try to implement a new block device acting as a wrapper between usb MSC and dhara [2] my (very basic) NAND flash driver:

USB MSC <===> bock_dev <===> dhara FTL lib <===> my custom basic NAND driver

Dhara is a small flash translation layer designed to be used in
resource-constrained systems for managing NAND flash. It provides a
mutable block interface with standard read and write operations. It has
the following additional features:

  * Perfect wear-levelling: the erase count of any two blocks will
    differ by at most 1.

  * Trim: logical sectors can be deleted to improve performance if their
    content is not required.

  * Data integrity: write() (and trim()) of logical sectors are
    atomic. If the power fails, the state rolls back to the last
    synchronization point. Synchronization points occur at regular
    intervals, but can also be reached on demand.

  * Real-time performance: all operations, including startup, are O(log
    n) worst case in the size of the chip, if bad blocks are uniformly
    distributed.

Another solution would be buying a FTL IP and integrate it in place of Dhara.

[1] github.com/.../LittleFS-Explorer-for-Windows

[2] https://github.com/dlbeer/dhara

Thank you for your time. I'll update this thread as soon as I have news.

Best

[joel-sc]

Sorry I did not update this thread.

So I've managed to implement a custom block device which is using dhara as a FTL, then dhara will use my flash driver.

My POC works quite well for now, but I still one issue with interrupt priority (see [1]).

[1] devzone.nordicsemi.com/.../nrf_blk_dev_read_req-is-called-from-critical-region-in-the-sdk

Best,

[JONATHAN LL]

Thanks for updating this thread. 

[joel-sc]

Even if it is not planned in the Nordic roadmap. As I can see there is a lot of thread asking for NAND flash support in the Devzone so I really think this kind of feature (supporting a QSPI or SPI nand flash block device) would be benefit for the SDK users.

The hard part will be in the FTL implementation but maybe dhara could be integrated as an external dependency.

Best,

Joël

[JONATHAN LL]

Thanks for the feedback Joël, I do agree that it would be beneficial as there is a good amount of ticket here on DevZone with that topic, but currently there has not been enough interest form the community/customers for it ot be a prioritization. Thanks again for sharing your opinion :)

Regards,
Jonathan