STM32F746 Timing Strangeness

jerry2 · ‎2022-02-17

I've got a Nucleo-F746 board and have noticed a code execution time anomaly that I can't explain.

The code running is very simple:

unsigned int j = 750000;
while(j--)
     ;

Essentially a loop that does nothing except waste time. When I run this on the board and time the loop with the SysTick timer, I get different results depending on whether I build and run the code with Atollic True Studio, STMCubeIDE (v1.8.0), or Segger Embedded Studio. The loop takes twice as long to run under STMCubeIDE than it does on the other two.

This is not a code optimization issue, because the assembly code generated for the while loop by all three tools is exactly the same (and it runs with interrupts disabled):

loop:
ldr    r3,[sp, #4]
subs   r2,r3,#1
str    r2,[sp, #4]
cmp    r3,#0
bne.n  loop

I'm not using the IDE-provided startup code. I'm doing it all myself, including setting up the STM32's clocking, initializing the SysTick timer and caches, prefetch etc. The code is identical across all three IDEs, and I've verified that after it runs the system registers for clocking, etc., are exactly the same.

What makes this stranger is that when this code is run on STMCubeIDE, the stack, where the counter for the loop is stored, is in DTCM memory, while it's in SRAM1 when running on Embedded Studio. In both cases, the code itself is running from the same part of FLASH memory.

This has me really puzzled. Anyone have any ideal what may be going on?

jerry2 · ‎2022-02-19

That’s an interesting point. I’ll move the code to 0x0200 0nnn and see if that makes a difference. I’m skeptical that this will speed the loop up by a factor of two, however. It also doesn’t explain why the loop runs twice as fast when the app is built with Atollic or Embedded Studio versus STM32CubeIDE because all three put code in flash at 0x0800 0nnn.

To rule out the debugger having an influence, I use the delay loop to time turning an LED on and off. Now I can unplug the Nucleo board from the PC and plug it into a USB powerpack that just provides 5v DC. When I do this, the code compiled under Atollic or Embedded Studio blinks the LED twice as fast as when the code is built with STM32CubeIDE.

waclawek.jan · ‎2022-02-19

Reduce code to complete compilable but absolute minimum exhibiting the problem, ideally with no library calls, and post.

JW

Danish1 · ‎2022-02-20

And the other thing you might check is the Memory Protection Unit MPU (see Cortex M7 programming manual rather than reference manual).

If the MPU is enabled, it can allow cacheing and/or write-back rather than write-through.

Maybe some startup codes enable it, others not.

And it can be different for different regions of memory.

Regards,

Danish