`FLEXSPI_TransferBlocking` is not suited for erase operation
Closed this issue · 4 comments
The NXP FLEXSPI_TransferBlocking function is not suited for erase operations in QSPI/HyperFlash devices since it is not polling the status register of the flash chip but just evaluating the bus signals.
That is a problem since the erase operation will be performed by the device without any feedback - hence the bus is idle and the function will return. Polling of the status register of the flash device is required to ensure correct and robust operation.
As far as I recall, the call to flexspi_nor_wait_bus_busy() checks the busy bit in the QSPI chip status register. That bit is set as long as an erase operation takes place.
E.g. from the data of W25Q64FV:
"BUSY is a read only bit in the status register (S0) that is set to a 1 state when the device is executing a Page Program, Quad Page Program, Sector Erase, Block Erase, Chip Erase, Write Status Register or Erase/Program Security Register instruction. "
Yes - I was just not sure if it is really reading back that bit. From time measurements I got the inkling that the peripheral is actually polling the register but I need to confirm with a trace to calm myself :-).
From the work with the MIMXRT1050_EVK, where the block erase lasts 1 s and more, I can tell that the code indeed blocks. Writing a series of files to flash sometimes stops for a while, and bdev.ioctl(6, x) (block erase) take a while to return.
Ok. That would be good. I need to check the Block size we use for VFS. The QSPI devices support a block erase of either 32k or 64k with 0.5s or 1s worst case execution time (but much faster with new devices). Since the HyperFlash devices only support a sector erase of 256k sector if I am not mistaken I see a potential to speed up flash file system operation significantly.