I am using the FlexSpi interface to talk to a NOR flash. It works fine in general and flash writes of 256 bytes and 16 bytes are both successful. I recently added a read-verify routine after the flash write and that is where I see the problem. 256 byte writes are still ok and the read verify passes. However, with the 16 byte writes, only some of the read-verify operations passed; most of them failed. The failures did not seem to correlate to the number of 16 byte blocks written/write address alignment.
Code snippet in question:
flashXfer.deviceAddress = destAddr - FlexSPI_AMBA_BASE;
flashXfer.port = FLEXSPI_FLASH_PORT;
flashXfer.cmdType = kFLEXSPI_Write;
flashXfer.SeqNumber = 1;
flashXfer.seqIndex = FLEXSPI_PROGRAM_PAGE_LUT_SEQ_INDEX;
flashXfer.data = (uint32_t *)pSrc;
flashXfer.dataSize = numBytes;
status = FLEXSPI_TransferBlocking(FLEXSPI, &flashXfer);
if (status == kStatus_Success)
mcuStatus = _FlexSpiCheckIfFinished();
mcuStatus = MCU_STATUS_TIMED_OUT;
DCACHE_InvalidateByRange(destAddr, FLASH_PAGE_SIZE); // 256 byte pages - writes no more than a page at a time
// I also looked into the 32-byte alignment of the cache invalidate routine and tried replacing this by CACHE64_InvalidateCache(CACHE64); - same problem
// Read from memory mapped flash address and memcmp(). This passed when writing 256 bytes at a time, but failed for 16 byte writes. I also tried 32, 64, 128 byte writes and those fail as well.
Hi Raymond Yip ,
Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
According to the above code, it completes the page program operation via the IP command, this page program command is fetched from the LUT.
In further, the commands in LUT should be suited for the target QSPI, in another word, the commands should correspond with QSPI's commands which are indicated in its datasheet.
Back to your question, I'd like to suggest you check the minimum unit of bytes of the page program command in the QSPI's datasheet, it will give you some clues.
We are using page program command 0x02 in the LUT, so that has no limitation on the number of bytes programmed.
We found the issue and it was due to a missing call to FLEXSPI_SoftwareReset() after the calling the flash write API noted above. Can you please explain if this is necessary after every call to FLEXSPI_TransferBlocking() and why it is necessary?