RT1021 FlexSPI IPCMDDONE interrupt/flag appears to arrive early when reading?

[rshipman]

Hi,

I am using the fsl_flexspi.c driver to access NOR flash. The blocking API seems to work ok, but when I switched to the non-blocking functions, I found that reading from flash failed for a 4096 block. In fact, it fails for any block length > 8 bytes.

If I read a block of 4096 bytes, the IPCMDDONE flag is raised before all the bytes are received. It seems to consistently occur when 120 bytes are remaining to be read. If I modify the isr so that it effectively ignores the IPCMDDONE flag, then it carries on receiving bytes and I get the full 4096 byte block. So I have modified fsl_flexspi.c to workaround this issue.

My questions are:

• Is this expected behaviour? Shouldn't the IPCMDDONE flag be raised when all 4096 bytes have arrived?
• Is there something missing from the driver? E.g. another flag to check?
• Am I simply not setting something correctly?

I have uploaded my demo project that shows this problem.

It is basically the evkmimxrt1020_iled_blinky demo with evkmimxrt1020_flexspi_nor_polling_transfer merged in. The demo is modified so that it runs from internal ram (SRAM_OC). I have copied the file flexspi_nor_flash_ops.c to flexspi_nor_flash_ops_non_blocking.c. Both files have been modified, the latter uses the non-blocking api.

Note:

• Both I and D caches are disabled.
• I'm not using the AHB feature - disabled.

In main() it does the following (after the initialisation etc):

• Blocking: erase chip.
• Blocking: program 4096 bytes using a repeating pattern of 1 - 0x80.
• Blocking: readback and check it is correct.
• Non-blocking: readback and check it is correct. This fails without my workaround.
• Non-blocking: erase chip
• Non-blocking: readback and check. This fails without my workaround.
• Non-blocking: program 4096 bytes using a repeating pattern of 1 - 0x80.
• Non-blocking: readback and check. This fails without my workaround.
• Non-blocking: erase sector
• Non-blocking: readback and check. This fails without my workaround.
• Flash led when done.

In MCUXpresso change the settings so that the preprocessor symbol is as follows:

• To see the problem.
  • EARLY_IPCMDDONE_WORKAROUND=0
• To enable the workaround
  • EARLY_IPCMDDONE_WORKAROUND=1

This is what I saw with different block lengths (change TEST_BLOCK_SIZE):

Block length bytes	Remainder when IPCMDDONE received	Result
4096	120	Fail
2048	120	Fail
1024	120	Fail
512	120	Fail
256	120	Fail
128	112	Fail
64	48	Fail
32	24	Fail
16	8	Fail
8	0	Pass
4	0	Pass
1	0	Pass

The workaround is as follows (not necessarily the best way):

• In the FlexSPI ISR in fsl_flexspi.c (FLEXSPI_TransferHandleIRQ):
  • When the IPCMDDONE interrupt flag appears:
    • If we are expecting more data, then we just make a note that the IPCMDDONE interrupt has been received.
    • If all the data has been received, then we call the callback.
  • When the number of bytes we are expecting has been received then
    • If IPCMDDONE interrupt flag has been seen, then we call the callback.
    • If IPCMDDONE interrupt flag has not been seen, then we wait for it.

IMPORTANT: This mechanism relies on the flexspi_transfer_t::dataSize field being set to a valid size or zero for this to work, especially for commands that do not take a size, such as chip erase. If dataSize is set to a non-zero value for chip erase etc, then the callback will not be called.

Info:

• MCUXpresso v11.9.1
• SDK_2_15_100_EVK-MIMXRT1020
• Eval board: MIMXRT1020-EVK, SCH-29856 REV A3, TDA6595, 700-29856 REV A, TR18290644
• Our own prototype board exhibits this behaviour as well. (Based on RT1021, with a Micron flash fitted.)

Thanks for your help.

Kind regards.

[Habib_MS]

Hello @rshipman ,

Thank you for providing us this workaround solving the problem, I'm going to contact the internal SDK group so they can deliberate about the addition of this fix on a future SDK release.

With respect of your questions, as soon as we have a correct answer to these, we will let you know.

BR,
Habib.