QSPI STM32F767xx reads wrong data

[Arnab]

Using STM32F767xx as QSPI master and Cortex M33 as a slave 

While reading the header (4 bytes) i see the first 2 bytes are correct always and the last 2 bytes as 0xFF's. If i take a capture directly from the QSPI pins on the slave i see correct values but as soon as i connect STM and capture on the STM QSPI lines it's all wrong.

GPIO configurations :

GPIO_InitStruct.Pin = GPIO_PIN_2;

  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

  GPIO_InitStruct.Pull = GPIO_NOPULL;

  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

  GPIO_InitStruct.Alternate = GPIO_AF9_QUADSPI;

  HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

  GPIO_InitStruct.Pin = GPIO_PIN_2;

  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

  GPIO_InitStruct.Pull = GPIO_NOPULL;

  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

  GPIO_InitStruct.Alternate = GPIO_AF9_QUADSPI;

  HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

  GPIO_InitStruct.Pin = GPIO_PIN_10;

  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;

  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

  HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

  GPIO_InitStruct.Pin = GPIO_PIN_11|GPIO_PIN_12|GPIO_PIN_13;

  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

  GPIO_InitStruct.Pull = GPIO_NOPULL;

  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

  GPIO_InitStruct.Alternate = GPIO_AF9_QUADSPI;

  HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

QSPI Initialization :

hqspi.Instance = QUADSPI;

  hqspi.Init.ClockPrescaler = 4;

  hqspi.Init.FifoThreshold = 8;

  hqspi.Init.SampleShifting = QSPI_SAMPLE_SHIFTING_NONE;

  hqspi.Init.FlashSize = 10;

  hqspi.Init.ChipSelectHighTime = QSPI_CS_HIGH_TIME_1_CYCLE;

  hqspi.Init.ClockMode = QSPI_CLOCK_MODE_0;

  hqspi.Init.FlashID = QSPI_FLASH_ID_1;

  hqspi.Init.DualFlash = QSPI_DUALFLASH_DISABLE;

Command :

sCommand.Instruction = 0x35;

 sCommand.DummyCycles = 0; 

 sCommand.NbData = spiSize; 

 sCommand.InstructionMode = QSPI_INSTRUCTION_4_LINES;

 sCommand.AddressMode = QSPI_ADDRESS_NONE;

 sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;

 sCommand.DataMode = QSPI_DATA_4_LINES;

 sCommand.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;

 sCommand.DdrMode = QSPI_DDR_MODE_DISABLE;

Attached both valid and invalid captures for reference

[ChahinezC · Accepted solution]

Hello @Arnab​,

I recommend you verifying if the QUADSPI peripheral enters memory-mapped mode with bits ADDRESS[1:0] of the QUADSPI_AR register both set; it might cause a wrong data from memory-mapped read after an indirect mode operation

Regards,

Chahinez.

[Tesla DeLorean]

@ChahinezC​ is this something specific to the F767 implementation, or would we expect to see similar behaviour across other STM32 families, and QUAD / OCTO implementations. Thanks -Clive

[Tesla DeLorean]

A lot of examples has sCommand as a local/auto variable, I'd recommend clearing that so the structure has predictable content, not random stuff from the stack, as the HAL pulls and combines bits from multiple fields to construct the QSPI register settings.

Using the assert() methods to pin point parameter issues can also be useful in catching / containing odd behaviour.