RT6xx FlexSpi - Flash write-read-verify fails for small writes

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RT6xx FlexSpi - Flash write-read-verify fails for small writes

929 Views
rayip
Contributor II

Hello,

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();
}
else
{
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.  

Labels (1)
Tags (1)
0 Kudos
2 Replies

852 Views
jeremyzhou
NXP Employee
NXP Employee

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.

Have a great day,
TIC

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

852 Views
rayip
Contributor II

Hi Jeremy,

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?