Why does the execution time of STM32F767ZIT6 (used in NUCLEO-F767ZI) not grow as expected when the amount of code to execute increases?

[Silvano]

I measure the execution time of a function by putting the toggle of a digital output and the function call into a cycle and measuring the period of the square wave at the digital output with an oscilloscope. The execution time is half a period.

To test the procedure, I used instead of the function a dummy code (see main function in the annex execution_time_main.c) where the cnt_max parameter allows me to vary the amount of code to execute.

The measured periods are visible in the attachment CRAZY_TIMES.jpg

I do not understand why both with the ARM V5 and V6 compiler in Keil uVision the trend of the periods is that shown in the attachment CRAZY_TIMES.jpg

• Comp V5, test case 8 to 9 cnt_max go from 8000 to 9000 (increases) and  period go from 485 us to 454 us (decreases) !
• Comp V5, test case 10 to 11 cnt_max go from 10 000 to 100 000 (x 10) and period go from 505 us to 11.1 ms (x 22) !
• Comp V6, test case 10 to 11 cnt_max go from 10 000 to 100 000 (x 10) and period go from 607 us to 29.6 ms (x 49) !

Thanks

[TDK]

The M7 pipeline is considerably more complex than a PIC or 68000 which leads to things like this. You have 7 wait states and if the processor needs to load two different pages, it will take some time. You can't get away with the simplicity of a constant X cycles per instruction when you're running at several hundred MHz. Things are exacerbated when your code is otherwise so short. Enabling ART Accelerator may eliminate this effect entirely, would be interesting to see.

[Silvano]

In my original problem, the clock was at 216 MHz and consequently the wait states were actually 7. Now the clock is at 16 MHz and there were no wait states. See tab 7 in the reference manual RM0410 rev 4 below..

[Silvano]

Hi @Tesla DeLorean (Customer)​, @KiptonM (Customer)​, @TDK (Customer)​ and @LCE (Customer)​ 

Tesla DeLorean is right :)

I tried to enable the cache and almost all the previous anomalies disappeared. The only "anomaly" left is the one reported on February 16, 2022 at 11:20 AM (I do not understand why ... test case 8 to 9 cnt_max go from 8000 to 9000 (increases) and period go from 485 us to 454 us (decreases)! ). Likely, as already said by you, could be the compiler rearranging things based on the compiled value.

Are there any reasons for deciding not to enable the cache?

[Silvano]

Hi @Tesla DeLorean (Customer)​, @KiptonM (Customer)​, @TDK (Customer)​ and @LCE (Customer)​ 

Thank you all for the time you have dedicated to me.