Cycle Counter different when stepping

[TLudw]

Hello,

I'm currently doing some performance measurements using the DWT's CYCCNT register. As I understand the RM, the CYCCNT counts up for every core clock cycle (except when halted).

However, I get different values in CYCCNT when stepping through the code, vs running it. (Running is approx. 80 cycles higher). How can this be explained? Shouldn't the cycle count for the stepping mode be higher (because additional bus transactions by the debug module)?

The setup:

MCU: STM32F103C8T6 (Cortex M3)

Core-Clock: 72MHZ

Thanks in advance and best regards.

[waclawek.jan]

When single- stepping, after a step, the core instruction execution stops and so does CYCCNT, but the elements external to the core continue to work and perform tasks for which the core in run would wait - e.g. FLASH can prefetch the next line, write from write buffer into a slow peripheral will be finished, etc.

JW

[TLudw]

Thank you very much.

So is the prefetch unit (mentioned in the Cortex™-M3 Technical Reference Manual) the same as the prefetch buffer in the flash controller?

[Tesla DeLorean]

I probably wouldn't say they are the same, the core might hold some state, I don't know. But as you describe it single stepping hides the flash latency. Consider methods other the single-stepping to understand your code behaviour.

The F1 has an exceedingly slow FLASH exposed to the core, the F2/F4 designs mask this with the ART cache.

In 2019 seriously consider a better STM32 part.

[TLudw]

I know about the ART but it was until recently that I discovered they are not available for the Cortex-M3 (F1xx) family. Unfortunately, I can't switch the device during this project, but I will keep it in mind for further ones.

[S.Ma]

When running the code, there might be ISR (interrupt service routine) which bumps cycles. In step by step mode, it depends on how the debugger works, and obviously the interrupts are disturbed. Try with interrupts disables to see if there is a dependency.