QSPI unexpected clock behavior STM32H723VGTx

[Jurni_JasteD]

Dear Community,

for my application I use the STM32H723VGTx where I'm using the OSPI interface as a SPI and QSPI to control a external sensor (MCU SPI master, sensor SPI slave). Now I face some issues with this communication interface, for debugging reasons I did some logic analyzer measurement, which I've attach to this post.

The problem is that while reading the sensor registers in QSPI mode the CLK (green signal) of the STM32 has some breaks like you can see in the following screenshots.

Long reading operation QSPI, CLK breaks

This behavior is shown only for larger reading operations, like you can see for a shorter reading operation in the following screenshot. But here I have also a question: why is there this last Low -> High -> Low change for the DIO3 shortly after CSN (red) is went HIGH again?

Short reading operation QSPI, DIO3 issue at the end of receiving

In single line SPI mode there are no such problem with the CLK, here the CLK is running without breaks while CSN is Low like you can see in this screenshot:

Single Line SPI reading -- no issue

The interface settings are like this:

1.  OSPI Init Settings:
   hospi1.Instance = OCTOSPI1;
   hospi1.Init.FifoThreshold = 1;
   hospi1.Init.DualQuad = HAL_OSPI_DUALQUAD_DISABLE;
   hospi1.Init.MemoryType = HAL_OSPI_MEMTYPE_MACRONIX;
   hospi1.Init.DeviceSize = 32;
   hospi1.Init.ChipSelectHighTime = 1;
   hospi1.Init.FreeRunningClock = HAL_OSPI_FREERUNCLK_DISABLE;
   hospi1.Init.ClockMode = HAL_OSPI_CLOCK_MODE_0;
   hospi1.Init.WrapSize = HAL_OSPI_WRAP_NOT_SUPPORTED;
   hospi1.Init.ClockPrescaler = 4;
   hospi1.Init.SampleShifting = HAL_OSPI_SAMPLE_SHIFTING_NONE;
   hospi1.Init.DelayHoldQuarterCycle = HAL_OSPI_DHQC_DISABLE;
   hospi1.Init.ChipSelectBoundary = 0;
   hospi1.Init.DelayBlockBypass = HAL_OSPI_DELAY_BLOCK_BYPASSED;
   hospi1.Init.MaxTran = 0;
   hospi1.Init.Refresh = 0;
   sOspiManagerCfg.ClkPort = 1;
   sOspiManagerCfg.NCSPort = 1;
   sOspiManagerCfg.IOLowPort = HAL_OSPIM_IOPORT_1_LOW;
   
   
2. QSPI Settings:
   qspiCommand.InstructionMode = HAL_OSPI_INSTRUCTION_NONE;
   qspiCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
   qspiCommand.AddressSize = HAL_OSPI_ADDRESS_8_BITS;
   qspiCommand.AddressMode = HAL_OSPI_ADDRESS_4_LINES;
   qspiCommand.Address = 0x00;
   qspiCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
   qspiCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
   qspiCommand.AlternateBytesDtrMode = HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;
   qspiCommand.DummyCycles = 2;
   qspiCommand.DataMode = HAL_OSPI_DATA_4_LINES;
   qspiCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
   qspiCommand.NbData = DATA_SIZE
   qspiCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
   qspiCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
   
   
3. QSPI Function Calls:
   HAL_OSPI_Command(&hospi1, &qspiCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE);
   HAL_OSPI_Receive(&hospi1, (uint8_t*) &bgt_buffer_burst_all_reg[0], HAL_OSPI_TIMEOUT_DEFAULT_VALUE);
   
   
4. Single Line Settings:
   spiCommand.InstructionMode = HAL_OSPI_INSTRUCTION_NONE;
   spiCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
   spiCommand.AddressSize = HAL_OSPI_ADDRESS_32_BITS;
   spiCommand.AddressMode = HAL_OSPI_ADDRESS_1_LINE;
   spiCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
   spiCommand.Address = ADR;
   spiCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
   spiCommand.AlternateBytesDtrMode = HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;
   spiCommand.DummyCycles = 0;
   spiCommand.DataMode = HAL_OSPI_DATA_1_LINE;
   spiCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
   spiCommand.NbData = DATA_SIZE;
   spiCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
   spiCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
   
   
5. Single Line SPI Function Calls:
   HAL_OSPI_Command(&hospi1, &spiCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE);
   HAL_OSPI_Receive(&hospi1, (uint8_t*) &bgt_buffer_burst_all_reg[0], HAL_OSPI_TIMEOUT_DEFAULT_VALUE);
   
   
   I hope there is a solution for this issue of the QSPI CLK. Thank you all in advance!
   
   Best regards,
   Jurni_JasteD

[waclawek.jan]

Without attempting to gain deeper understanding, isn't it simply the case that the processor can't read out data from QSPI fast enough to keep the clock continuous?

JW

[Jurni_JasteD]

Hello JW,

thank you for your anwser!
I've tested my code with a lower CLK frequency (<20 MHz) and now I get a continuous CLK!

Now I have a question based on this, I made further tests where i use these QSPI read operations with provided MDMA for the OSPI interface, Here I would have expected that I get a continuous CLK with a 50 MHz CLK again, because the processor is unloaded.
Now I wonder what the specified maximum data rate/ CLK frequency is for the STM32H723 for a SDR communication, because in the Application Note OSPI I it is not specified for the MCU I'm using.

Are there any settings that allow to implement a reliable QSPI interface for a CLK frequency >20 MHz?

Best regards,
Jurni_JasteD

[KDJEM.1]

Hello @Jurni_JasteD ,

Thank you for bringing this typo to our attention.

I confirm that ,for STM32H72x/3x, the Max OCTOSPI speed Regular-command SDR mode / Regular-command DTR mode with DQS HyperBus protocol with single-ended clock (3.3 V) values are missing in AN5050 rev8 table2.

The correct Max OCTOSPI speed values for:

-Regular-command SDR mode is 140MHz.

-Regular-command DTR mode with DQS HyperBus protocol with single-ended clock (3.3 V) is 100MHz.

This issue is reported internally.

Internal ticket number: 154620 (This is an internal tracking number and is not accessible or usable by customers).

Kaouthar

[Tesla DeLorean]

Perhaps deepen the FIFO ?

[Tesla DeLorean]

hospi1.Init.FreeRunningClock = HAL_OSPI_FREERUNCLK_DISABLE; // Turns it off when not active

Memory Mapped mode should allow for a saturated read operation to the maximal bandwidth of the memory, less whatever other contention, and interrupts, etc you're dealing with.

[Andreas Bolsch]

The "glitch" on DIO3 is most likely a result of dynamic switching capability between 1-line and 4-line mode. In 1-line mode, the pin DIO3 is nHOLD for the flash chip (note again: the QSPI interface had been designed with memory devices in mind), so its inactive state is '1', whereas the inactive state for DIO2 is '0' as it nWP for the flash.

So after a 4-line transfer phase, the pins probably return to default state for 1-line mode, and are deactivated only then. However, that's not a deficiency nor a bug, as ST does assure functionality for memory devices only, and for these, this glitch is irrelevant as it occurs with sufficient delay after CS goes inactice. 

For devices other than memory I'm afraid it's just like this: YMMV