In STM32H750, how to properly configure QSPI to work with Cache?

[DPade.1]

I have an application on STM32H750 which runs out of QSPI in XIP mode. After init, I enable the cache with SCB_EnableICache() and SCB_EnableDCache(). After this point, the application goes to a continuous loop which just calls the same small function repeatedly, so I expect this loop and function should be executing completely out of cache. However, I noted that the data lines to the QSPI are still active. If the data in QSPI has been cached, I expect no need for the system to access the QSPI interface...does this mean the cache is not actually working? Do I need to enable a DMA to support the cache mechanism?

[Pavel A.]

Is your vector table in QSPI as well? Getting any interrupts (systick...) ?

[DPade.1]

Yes, the application's vectors are also in QSPI, and the SCB->VTOR has been set accordingly. I have a timer which is running by IRQ and it is running.

I may have a misunderstanding on my part. I was trying to run a test function to measure the difference in performance between the QSPI and internal flash with and without cache enabled. I just tried running the tests with the MPU disabled (commented out the call to MPU_Config()), and now the QSPI execution speed is MUCH slower. This might mean the cache was working all the time even when I wasn't expecting it. It also appears the QSPI is being accessed much more often than my previous measurements.

To your question, are you thinking that the NVIC is causing the accesses to the QSPI...and that the interrupts are not cached...or that the MPU is disabled during IRQs?

[Pavel A.]

> are you thinking that the NVIC is causing the accesses to the QSPI.

If your vector table is in QSPI and all handlers are in QSPI, then the systick interrupt hits it every millisecond. At least.

>  I just tried running the tests with the MPU disabled (commented out the call to MPU_Config()), and now the QSPI execution speed is MUCH slower. This might mean the cache was working all the time even when I wasn't expecting it.

Need to check the default attributes of the QSPI area - is it normal or device?

ICACHE won't enable itself unless you enabled it explicitly.

[DPade.1]

According to the Reference Manual, the QSPI region is Normal, Write-through cache, Execution enabled.

I would have expected that once the interrupts were hit the first time, they would continue to be executed out of cache afterward. Is this not the case?

[Tesla DeLorean]

See MPU_Config() section here

STM32Cube_FW_H7_V1.8.0\Projects\STM32H750B-DK\Demonstrations\MenuLauncher\Core\Src\main.c

Seem to recall there being an App Note also

[Tesla DeLorean]

https://community.st.com/s/question/0D53W000010uOOcSAM/stm32h750-mpu-xip

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/STM32H750B-DK/Demonstrations/MenuLauncher/Core/Src/main.c#L270

My take aways are that you first need to establish the region as 256MB (full 0x90000000 decode space) to be strictly ordered, and then get a readable/executable region that is the size of the underlying device. Perhaps 16MB, or whatever portion you're using for code.

[DPade.1]

I think I understand the recommendation, however, I don't think I am in danger of getting speculative reads in the unused region since I am using only the first 23K of the available 4MB. However, I'm not familiar with how the speculation works...maybe it is still getting hits to an otherwise unused or unneeded area.

I will adjust my MPU_Config() to use a similar setup and see if it has any impact on performance when cache is enabled.