Getting huge different Delay time in measuring a blocking delay timer which run in different memory address of STM32H7a3ii. Was this behavior of the MCU?

[WChan.5]

I create a simple blocking delay timer using simple looping and run in STM32H7a3ii. The program was linear, no code optimization, no interrupt. Without any changes of the blocking delay timer function, i found that when the blocking delay timer placed in certain address, it gave me a huge different delay time. the varies was about 6 times different. Please assist me for this behavior.

[Tesla DeLorean]

Instead of iterations of a loop, use a reference like a free running TIM CNT register or DWT CYCCNT

C​heck memory is cachable

[WChan.5]

Thanks for the advice but I wish to use iteration to achieve the delay effect. The behavior mentioned was weird. example the placing the function in 0x24022EF8, it returns me the expected delay time. when it was in 0x24022F10, it returns me about 6 times from my expected delay time and every 0x20 different, the problem will occur.

[FBL]

Hello @WChan.5​, 

May I ask you how do you measure the performance of the blocking delay timer? Are you enabling the cache?

Thanks

Firas

[FBL]

@WChan.5​ Note that the microcontroller may have different access times to different regions of memory.

[WChan.5]

Hi @F.Belaid​,

I toggle 1 of the pins in the MCU and probe the signal using oscilloscope to measure the delay time. Having minor different time delay was acceptable for me as using iteration was not a precise method but the difference getting was way too big. if not mistaken, cache was enabled by default in stm32h7a3ii and no other way to disable it. am i correct? i tried called SCB_InvalidateICache(), SCB_InvalidateDCache(), SCB_CleanDCache() to clean the instruction and data cache before performing the delay timer but still having the same problem.

[WChan.5]

@F.Belaid​ , The problem occurred in same memory region. example, it happened in address A, it will also happen in address ( A+0x20 ) and so on

[FBL]

@WChan.5​, 0x20 is the size of a line of cache (256bytes). It is possible that it could be a cache miss.

You may need to Clean the cache first then Invalidate it. So, the content will not be corrupted. Using a function like

SCB_CleanInvalidateDCache(). This will ensure that the cache is completely invalidated and flushed, so that subsequent reads from memory will not be affected by stale data in the cache.

Hope this helps!

[Piranha]

Of course, you "forgot" to mention that such a global operation on all of the D-cache will corrupt all cacheable DMA Rx buffers, if there are such.

[Piranha]

> cache was enabled by default in stm32h7a3ii and no other way to disable it

Maybe try reading the documentation and looking at code? The cache is not enabled by default and obviously it can be enabled and disabled at any time. But it seems that on Cortex-M7 the alignment to cache lines has an impact on performance even with a disabled cache.

You can get a minimum time delay loops but not accurate ones on such a complex MCUs, especially with a Cortex-M7. Tesla's advice really is the correct solution to the problem. Take a note that for a delay you only need to read the counter - otherwise the timer can generate the PWM or do whatever else it does. And, if you implement it correctly, you can base your delay even on a SysTick, which at the same time can still serve as a system tick timer.