STM32H745ZIT6 QSPI fails to read any byte 0x0b from a NOR flash

[DUgbo.1]

Using

STM32CubeIDE - C/C++ 1.6.0.202101291314

STM32Cube FW_H7 V1.9.0

Hardware

NUCLEO-H745ZI-Q

IS25LP128(Flash Chip)

The flash is connected to QSPI bank 1 using the HAL libraries to read from an address on the flash

if(HAL_QSPI_Command(&hqspi, Cmd, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) == HAL_OK)
{
  if(HAL_QSPI_Receive(&hqspi, buffer, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) == HAL_OK)
  {
     status = QSPI_OK;
  }
}

if the data to be read on the flash is {1, 2, 3} the above works using a read instruction(0Bh) with QSPI_DATA_4_LINES

if the data to be read on the flash is {1,11, 3} (11 is 0x0B) then the read instruction(0Bh) fails.

This is repeatable with different lengths of data and at different addresses; a byte 0x0B can not be read into the read buffer with an instruction that has QSPI_DATA_4_LINES (same behavior using instruction EBh for this particular flash chip)

Read instructions with QSPI_DATA_1_LINE and QSPI_DATA_2_LINES will read any byte into the buffer

Both read instructions with QSPI_DATA_4_LINES fail once the data byte on the flash is 0x0B

Is this a known issue with the chip (STM32H745ZIT6)

[Tesla DeLorean]

>>Is this a known issue with the chip (STM32H745ZIT6)

Can't say I've encountered any data pattern sensitivity with Winbond or Micron parts. And to be honest this sounds like a memory IC side issue, no particular reason the STM32 would care about 0x0B specifically, it has no insight into the command set of the memory device, or necessity to pattern-match anything.

More prone to think it is a cross-talk or drive issue, or one with connectivity or part mode configuration. If you can get a logic analyzer on this, look for glitches on the NCS signal, and if the data bus tri-states. If you see a lot of ringing, try backing off the slew-rate settings (SPEEDR)

Are you using a foot-print that would accommodate alternate parts?

[Tesla DeLorean]

Whats the full part number and date code on the ISSI memory? Please attach a clear, in-focus shot of the device in question.

There looks to be known errata on parts prior to 2017 in Quad Mode

[DUgbo.1]

Used a logic analyzer to look at the signals between the STM32 and Flash chip. The data reported in my code matches the signals that is output by the Flash chip so it would seem the issue is external to the STM32. Will need to investigate further.

Could be a glitch on the CE line causing the Flash chip to stop outputting data, as after a failed read of 0x0B all subsequent data to the buffer is 0xFF. Looking at the signals(IO0 ...IO3) with a logic analyzer they all go high(equivalent to 0xFF).