Flash size setting for QSPI and OCTOSPI convention in STM32CubeMX

[Hueli.1]

I have a question about the convention in STM32CubeMX to specify Flash size for QSPI and OCTOSPI.

The two application notes do not state the same thing.

Application note for QUADSPI says: "Flash size is 16 Mbytes => number of bytes in Flash memory = 2[FSIZE+1] = 2[23+1] => FSIZE = 23"

 

Application note for OCTOSPI says:Which would mean that 24 stands for 16bytes.

So which one is true and which one should I use for the OCTOSPI

[MButsch]

I have basically the same question.

I am using the OCTOSPI1 controller on an ST32H723 with an MX25L3233 part (4megaBYTE).

If I configure DEVSIZE to "21" which docs say should allow access to 2^22 addresses, I cannot access beyond 2megabyte.

If i configure DEVSIZE to "22", I can access the entire 4 megabytes.

So how should DEVSIZE be configured?

[Tesla DeLorean]

QUADSPI and OCTOSPI are different controllers.

You're reporting behaviour as described in the OCTOSPI App Note

21 = 2 MB

22 = 4 MB

23 = 8 MB

24 = 16 MB

DEVSIZE is a 5-bit field in OCTOSPI_DCR1, where 2^(DEVSIZE+1) is the size.

The initialization code takes the DeviceSize field and does the subtraction

So Init.DeviceSize = 24 defines a 16MB device

STM32Cube_FW_H7_V1.8.0\Drivers\STM32H7xx_HAL_Driver\Src\stm32h7xx_hal_ospi.c

HAL_OSPI_Init

 /* Configure memory type, device size, chip select high time, clocked chip select high time, delay block bypass, free running clock, clock mode */
 MODIFY_REG(hospi->Instance->DCR1,
 (OCTOSPI_DCR1_MTYP | OCTOSPI_DCR1_DEVSIZE | OCTOSPI_DCR1_CSHT | OCTOSPI_DCR1_CKCSHT |
 OCTOSPI_DCR1_DLYBYP | OCTOSPI_DCR1_FRCK | OCTOSPI_DCR1_CKMODE),
 (hospi->Init.MemoryType | ((hospi->Init.DeviceSize - 1U) << OCTOSPI_DCR1_DEVSIZE_Pos) |
 ((hospi->Init.ChipSelectHighTime - 1U) << OCTOSPI_DCR1_CSHT_Pos) |
 (hospi->Init.ClkChipSelectHighTime << OCTOSPI_DCR1_CKCSHT_Pos) |
 hospi->Init.DelayBlockBypass | hospi->Init.ClockMode)); 

The memory devices themselves just tend to mask to the address bit counts they support, and the image you can read simply wraps within the address space.

In the STM32H74x/75x parts the last 32-bytes of the part have issues, I think there's an errata on that.

[MButsch]

Thank you for the explanation. i apprear to have been over thinking it a bit.