Winbond released two serial NAND flash memory chips in early 2018. The serial memory form factor using NAND technology makes this chip unique – it is lower cost compared to NOR flash of this size and can be used for IoT applications where large data storage space is required.
This note lists five observations made when I wrote ESP-IDF driver for integrating W25N01 with ESP32 in an IoT application.
Where W25N01 is great
As listed in the W25N01 Datasheet, there are a number of cases where the SPI NAND flash is great for IoT applications. After reading the following notes, you will realize that the NAND flash is best for use in cases that
- need sequential read operation
- need sequential write operation
- can afford to erase large 128KB blocks
- do not need read-modify-write operations on small data blocks
ESP32 and STM32 applications of this nature can be plenty out there. For example, the W25N01 is suitable for use as:
- graphics and font information storage
- audio file storage
- data logging in a circular queue style (oldest data overwritten)
- temporary storage for OTA firmware, large files or downloads
Where W25N01 is NOT that great...
Read on to find out the problems with replacing a regular NOR flash with Winbond’s serial NAND flash.
1. W25N01 package compatibility with W25Q64, etc (NOR flash)
W25N01 is completely pin-compatible with usual NOR flash chips that you regularly use. It uses the same pinout that WSON packaged NOR flash memory chips use.
Note that the W25N01 is not available in SOIC-8 package like most NOR flash chips are. This means that you cannot simply drop-in replace a NOR flash with W25N01 in many applications that use SOIC-8 footprint.
You can still solder a WSON chip into a WSOIC footprint. However, you risk shorting underlying vias because of the WSON packages’s exposed pad. So this can pass in prototyping, but not as a production choice.
You can also attempt to mount the serial NAND into a PSRAM footprint for prototyping (PSRAM interface and pinout is compatible with W25N01).
2. Only 4 partial page write operations allowed
NAND flash memories are not like NOR flash in many different ways. One such difference is the fact that you cannot usually write a sector or page partially more than 4 or 8 times.
Here is a post on what NOP4 or NOP8 partial write limitation means in the NAND world.
Let me explain. With NOR flash memories, you can only clear a bit.
When NOR flash is erased, all the bits are set. Therefore, you can always clear a bit that is set. However, you cannot set a bit that is clear. The only way to get a 1 instead of a 0 is to clear the whole page/sector.
This implies that you can write partial blocks, where you clear a bunch of bits. The bits that were not cleared still remain set and can be written to in the future.
However, because W25N01 is NAND based memory, you cannot do this an unlimited number of times. You can only partially write up to 4 times to a page. After that, you must erase the whole page even if you did not touch most of the page.
THE SOLUTION
The best way to tackle this issue is to not write partially to pages, unless you want to maintain a counter to keep track of partial writes.
You must always read-modify-erase-write, regardless of whether the page contained all 0xFF.
3. W25N01 erase block size is HUGE
This is probably the biggest difference between the usual NOR flash memory chips and W25N01. Unfortunately, this limitation makes it difficul to use W25N01 with ESP32 and STM32, or any other MCUs that have little SRAM to work with.
The minimum block size that can be erased is 128KB (kilo bytes). When you are trying to implement a filesystem, this can be a huge problem. Most filesystems work by writing small records such as entering a filename into the file table.
The minimum write size block of 128KB means that you must erase a whole 128KB block just to modify, say, 16 bytes of information in that block.
THE SOLUTION
You can reserve the last 8 MB of the NAND flash as “scratch” space and copy a sector into that scratch area. After that, you can simply erase the original block and read-modify-write it using the backup available in scratch area.
This adds a whole lot of work though, and takes up valuable time. Another catch would be managing wear leveling in the scratch region. A simple circular queue would probably work best.
4. Instruction format and sequencing differs from NOR flash
With NOR flash, you can usually randomly read data from anywhere in the storage space. You can seek a certain word in the memory array with one command.
However, with the W25N01, you must load or cache a page and then read the byte-level content. Random byte or word level access using a single instruction is not available.
If you are planning on doing a lot of random word/byte reads, this adds a lot of overhead to the SPI bus.
I believe this limitation buries the whole idea of executing code from the W25N01 NAND flash. If you have a whole lot of non-sequential access and little cache memory, your execution performance can take a serious hit. There are other limitations with the W25N01 that prevent the ESP32 from directly executing programs from the NAND flash. However, for MCUs with internal flash, you can still run code off the W25N01 using an STM32 with sufficient DRAM/SRAM.
5. W25N01 with ESP32 has some limitations
You could use the W25N01 with ESP32, but with quite some limitations. The best use case for using the NAND with ESP32 is when you need to record and read sequential data such as audio, but without a filesystem like FAT or SPIFFS.
- Default implementation of flash driver in ESP-IDF (at least up to v.5.0) only support up to 16MB flash (24-bit address). Not all ESP32 chip variants and IDF versions offer support for larger 32-bit address spaces required for flash chips like W25N01. Therefore, you cannot use W25N01 with ESP32 for main code execution.
- The ESP32 cannot use W25N01 with the internal hardware encryption API. Transparent hardware encryption has certain cache size limitations that prevent the W25N01 from being used as an external encrypted data storage device. You must custom-code all encryption and decryption routines that involves W25N01.
- You can still add W25N01 as a flash partition and write custom flash drivers for W25N01. This works fine as long as you just need to perform basic page-level read/write and can afford to erase an entire 128KB block at a time.
Having mentioned all this, I hope this article did answer a lot of your questions and can be helpful before you decide whether or not you would want to use the W25N01 in your ESP32 or STM32 project.
Feel free to ask away via the Quick Contact form in the sidebar, or leave a comment below.
Change Log
- 28 January 2023
– Initial Release