• State Verified Answer
  • Replies 8 replies
  • Subscribers 74 subscribers
  • Views 4748 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 268011
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents Reply
  • 0 in reply to joel-sc

    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

Children
  • 0 in reply to JONATHAN LL

    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

  • +1 in reply to 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,

  • 0 in reply to JONATHAN LL

    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

  • 0 in reply to joel-sc

    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

Related
Terms of service