SPIFlash support for W25N01GV

I am looking for a SPIFlash library which can support the Winbond W25N01GV - I can’t find any viable looking candidates/models written for Arduino I can understand.

The datasheet talks about running a check on and recording any bad blocks immediately received yet none of the libraries appear to support this. The models which support Winbond W25Q series appear to be subtly different but especially the addressing.

@rickkas7 Looking at your library SpiFlashRK could you help me understand where you got the following settings from for the Winbond flash?

		sectorEraseTimeoutMs = 500;
		pageProgramTimeoutMs = 10; // 3 ms actually
		chipEraseTimeoutMs = 50000;

And whether this conditional code only applies to this specific version of device OS or this and later versions?

#ifdef SYSTEM_VERSION_v151RC1
	// In 1.5.0-rc.1, SPI interfaces are handled differently. You can still pass in SPI, SPI1, etc.
	// but the code to handle it varies
	SpiFlashWinbond(::particle::SpiProxy<HAL_SPI_INTERFACE1> &spiProxy, int cs = A2) : 
		SpiFlash(spiProxy.instance(), cs) {
		setSettings();
	};
#endif

Lastly, for the functions readData() and writeData() the parameter addr passed to them is what address space value (bytes from start of the memory)?
Many thanks in advance for any light you can shed on this.

There is a table in the datasheet with those values. The chip erase time is longer because it takes longer on the larger chips. It’s just a timeout so you can set it longer than necessary.

The SYSTEM_VERSION_v151RC1 is that and later, however that particular fix is really only necessary for 1.5.1-rc.1 and is no longer necessary in later versions, but doesn’t hurt. I thought I removed it from the latest version, but maybe not for the SPI flash library.

Thanks for the pointer to W25Q64JV datasheet the best equivalent I can find in the W25N01GV datasheet is this

page program time = 1mS (actually 700uS)
Chip erase time - not given
Sector erase time - not given

The address space appears to be different as well - I assume this is treated as 0-128MB

NAND flash is pretty different from NOR flash and the SpiFlashRK library is not at all intended to support NAND flash.

There is no chip erase or sector erase on NAND flash, which is why those times are not listed. There is only a block erase on NAND flash, 128K on the W24N01GV. The sectors on most NOR flash are 4K.

On NOR flash, the addresses are linear from the start, with one exception. For NOR flash larger than 16 Mbyte (128 Mbit), they can operate either in paged mode with 24-bit addressing, or 32-bit linear addressing. There aren’t NOR flash larger than 4 GB so what happens when 32-bit linear addressing is no longer possible hasn’t been run into yet, but 40-bit addressing is theoretically possible.

WIth NAND flash it’s always paged read and write with a weird page size of 2,112 bytes for the W24N01GV. So you always have to set the page and work with a page at a time, for both read and write. The SpiFlashRK library only works in linear mode and has no concept of working with paged mode.

The other important thing with NAND flash is that you need to maintain the bad block list. For NOR flash, blocks fail only when writing. For NAND flash, blocks can also fail reading, which requires special bad block management. LittleFS sort of works with NAND flash, but does not have built-in support for read block failure management so you’d need to do that yourself.

I am aware of this ‘feature’ - thank you for the pointer about LittleFS. I assumed the main approach with bad block management was to pick up the bad blocks immediately the memory was received from the factory and thereafter to re-map the memory space around the bad blocks - so any read and write function handles this without the file system needing to know. The issue comes when the block fails later!

The weird page size of 2112 bytes is because of the extra 64 bytes used for ECC if enabled for each sector (512 bytes) in the main 2048 byte page area.

I am starting to think that maybe the W25Q256V - 32MB will be an easier route - I assume that SpiFlashRK with a tweak on the addressing will work?