Hi All
I have an issue with reading from QSPI flash via FlexSPI using a manual read (not XiP) in a certain case and am suspecting a problem in the FlexSPI itself.
- If the QSPI flash is read via XiP operations the data is correct but using a manual read there is a problem if one single byte is read from an address ending with 0x3 if a previous single byte was read from an address with the address ending with 0x2.
If the previous address was ending with 0x0, 0x1 or 0x3 there is no issue.
- if the single byte read from the 0x3 ending address that was bad is repeated it is then correct.
- It only happens when the LUT is configured for quad operation. If configured for single data line operation it is OK.
- I don't see that it can be a FW error since the FW sequence is identical in each case (FlexSPI register dumps in each case show them to be the same when it works and when it doesn't - apart from the read data value which corresponds to that seen on the bus.
- Bus clock rates don't make any difference.
Following are details of the problem, showing LUT values and FlexSPI bus recordings where the behavior is seen.
A:
FlexSPI register range dump showing the LUTs (for example). In this case the first LUT entry is being used by the fast QUAD read.
0xffff9010 0xffffffff 0x200081f7 0x00000078 0x00000000 0x00000061 0x5af05af0 0x00000001
0x80000020 0x80000020 0x80000020 0x80000020 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00008000 0x00000000 0x00000000 0x00000000 0x00020063 0x00000063 0x00000063 0x00000063
0x00000000 0x00000900 0x00000900 0x00000900 0x0d000c0c 0x00000001 0x00000000 0x00000000
0x00c00001 0x00000001 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000100 0x00000100 0x00000002 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000003 0x00000000 0x00000000 0x00000000 0x00000001 0x00000000 0x00000000 0x00000000
0x00000022 0x00000000 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x00ffffff 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x0a1804eb 0x26043206 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000406 0x00000000 0x00000000 0x00000000 0x08180420 0x00000000 0x00000000 0x00000000
0x08180432 0x00002220 0x00000000 0x00000000 0x20040431 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000460 0x00000000 0x00000000 0x00000000
0x20040401 0x00000000 0x00000000 0x00000000 0x24040405 0x00000000 0x00000000 0x00000000
0x24040435 0x00000000 0x00000000 0x00000000 0x20040411 0x00000000 0x00000000 0x00000000
0x24040415 0x00000000 0x00000000 0x00000000 0x08180452 0x00000000 0x00000000 0x00000000
0x081804d8 0x00000000 0x00000000 0x00000000 0x00000404 0x00000000 0x00000000 0x00000000
The LUT (read) entry itself is
FLEXSPI_LUT_1PAD_SEQ_1(FLEXSPI_Command_SDR, FAST_READ_QUAD_I_O) | FLEXSPI_LUT_4PAD_SEQ_2(FLEXSPI_Command_RADDR_SDR, ADDRESS_LENGTH_24BITS),
FLEXSPI_LUT_4PAD_SEQ_1(FLEXSPI_Command_DUMMY_SDR, 0x06) | FLEXSPI_LUT_4PAD_SEQ_2(FLEXSPI_Command_READ_SDR, DATA_LENGTH_32BITS),
which is the
"0x0a1804eb 0x26043206 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000"
where the QSPI flash command 0xeb is used (although the command is not relevant to the issue).
B. This is a read from the address 0x60c00002, which is normal (it happens to return 0x33 as data value, which is stored there) [ignore the SPI bus decoding for the address/data as it is in QUAD mode - only the command decoding is correct]
and this is a read from the following address (0x60c00003) if it is not performed after the previous address access (returning the value 0xd1 which happens to be stored there)
C. This is the recording if the 0x60c00003 byte is however read after the single-byte read of the address 0x60c00002 (or any other address ending in 0x2)
It is seen that the address sent on the FlexSPI bus is not the expected 0xc00003 but instead 0xc000ff !!!
D.
The manual read code is
// Command a read of 1 byte
ptrFlexSPI->FLSHA1CR2 |= FLEX_SPI_FLSHCR2_CLRINSTRPTR;
ptrFlexSPI->INTR = (FLEX_SPI_INTR_IPCMDDONE | FLEX_SPI_INTR_IPCMDGE | FLEX_SPI_INTR_AHBCMDGE | FLEX_SPI_INTR_IPCMDERR | FLEX_SPI_INTR_AHBCMDERR | FLEX_SPI_INTR_IPRXWA | FLEX_SPI_INTR_AHBBUSTIMEOUT | FLEX_SPI_INTR_SEQTIMEOUT)); // clear error flags
ptrFlexSPI->IPCR0 = ulOffset; // 0xc000002 and then 0xc000003
ptrFlexSPI->IPTXFCR |= FLEX_SPI_IPTXFCR_CLRIPTXF; // reset read/write pointers in IP transmit fifo
ptrFlexSPI->IPRXFCR |= FLEX_SPI_IPRXFCR_CLRIPRXF; // reset read/write pointers in IP receive fifo
ptrFlexSPI->IPCR1 = (((iID << FLEX_SPI_IPCR1_ISEQID_SHIFT) & FLEX_SPI_IPCR1_ISEQID_MASK) | ulLength); // iID = 0, ulLength is 1
ptrFlexSPI->IPCMD = FLEX_SPI_IPCMD_TRG; // manually start the transfer
E. As noted in the introduction, using a different LUT to perform the read using a 1-data width command instead:
{
FLEXSPI_LUT_1PAD_SEQ_1(FLEXSPI_Command_SDR, FAST_READ) | FLEXSPI_LUT_1PAD_SEQ_2(FLEXSPI_Command_RADDR_SDR, ADDRESS_LENGTH_24BITS),
FLEXSPI_LUT_1PAD_SEQ_1(FLEXSPI_Command_DUMMY_SDR, 0x08) | FLEXSPI_LUT_1PAD_SEQ_2(FLEXSPI_Command_READ_SDR, DATA_LENGTH_32BITS),
},
shows the FlexSPI bus performing as expected (the command sequence is identical as it is the LUT entry controlling the bus operation). This problem does not exist at all then.
F. A workaround in higher level FW is to do a dummy read of the 0x3 ending address if it follows a 0x2 addressed single byte read (which returns a bad value) and then repeating the same, which returns the correct value as the bus operation is correct.
G. XiP reads (using the same LUT entries) don't have any problem as they do burst reads of a number of bytes and not single byte reads
Conclusion:
- the issue is 100% repeatable and shows the problem on the FlexBus itself
- repeating the execution results in correct operation and it stays good until another 0x2 ending address read is performed
Question:
- are any such issues known in the FlexSPI?
Regards
Mark
