Skip to main content
Arnab
Visitor II
November 17, 2022
Solved

QSPI STM32F767xx reads wrong data

0693W00000WIe9vQAD.jpg0693W00000WIe9MQAT.jpgUsing 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

This topic has been closed for replies.
ChahinezC
ChahinezCBest answer
Associate II
December 14, 2022

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.

3 replies

ChahinezC
ChahinezCBest answer
Associate II
December 14, 2022

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
Guru
December 15, 2022

@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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Tesla DeLorean
Guru
March 21, 2023

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..