Hi,
I found a very strange behavior for our filesystem to erase/write flash via flexspi driver by calling FLEXSPI_TransferBlocking().
In our project, we are using RT1165 as MCU and two FLEXSPIs are used.
FlexSPI 1 is used for XIP flash (executing code) and FlexSPI 2 is used for flash of filesystem.
When the issue happened, our filesystem will erase/write flexspi2 flash at the same block address over and over again. It seems that the data read back from flash is different with data wrote to flash. And that is saying that for unknown reason data can't be wrote to flash via FlexSPI 2 correctly even if it can return true by calling FLEXSPI_TransferBlocking(). And this issue happened with very low rate.
The interesting thing is that if I add DisableGlobalIRQ() in FLEXSPI_TransferBlocking(), the strange issue will never happen.
So, my question is do we need DisableGlobalIRQ() in FLEXSPI_TransferBlocking()? And if yes, why do we need it and is there any explanation to help to clarify this issue.
Thanks & Regards,
Kyle
PS: codes changed to FLEXSPI_TransferBlocking()
Solved! Go to Solution.
If FlexSPI2 flash has nothing to do with XIP code, then you don't need to disable interrupt during calling FLEXSPI_TransferBlocking().
But there is limitation in current FlexSPI driver, you can try to modify driver as below. it could fix your issue.
This fix is ok for NOR flash with no more than 256bytes page size, and it is not ok for NAND Flash with large page size (eg, 4KB)
If FlexSPI2 flash has nothing to do with XIP code, then you don't need to disable interrupt during calling FLEXSPI_TransferBlocking().
But there is limitation in current FlexSPI driver, you can try to modify driver as below. it could fix your issue.
This fix is ok for NOR flash with no more than 256bytes page size, and it is not ok for NAND Flash with large page size (eg, 4KB)
Hi Jay,
Thanks for your reply, and it seems your change could work, and I will try to run the test again based on your code change to see if ffs corruption will happen again.
Thanks,
Kyle