STM32 - How to enable the DWT cycle counter

Question

I am using the STM32F7-Discovery board and trying to turn on the DWT loop counter. From what I saw on the Internet, this is enough to turn it on:

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= 1; 

However, when I run this code, the values ​​do not change or the operations are skipped (I'm not sure what is happening).

I tried making pointers to addresses in memory and changing them directly to no avail. Example:

 volatile uint32_t *DWT_CONTROL = (uint32_t *) 0xE0001000; volatile uint32_t *DWT_CYCCNT = (uint32_t *) 0xE0001004; volatile uint32_t *DEMCR = (uint32_t *) 0xE000EDFC; *DEMCR = *DEMCR | 0x01000000; *DWT_CYCCNT = 0; *DWT_CONTROL = *DWT_CONTROL | 1; 

Currently, the only way I got it is to go with the debugger in Visual Studios (with VisualGDB) if I changed the DWT-> CTRL value to ON, which starts the loop counter. Other than this, however, I cannot force the value to change the code.

Edit: what can cause behavior when these lines of code do not perform their tasks, but also do not fail and continue.

 CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= 1; 

After starting these lines of code, all values ​​in these memory cells remain unchanged and do not change during the execution of operations that should have been performed.

eg.:

 //DWT_CTRL_CYCCNTENA_Msk = 1 DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk 

This should result in a DWT-> CTRL value of 0x40000001, but it remains the default 0x40000000

The following are examples of what happens at runtime.

Before after

Answer 1

Perhaps missing to unlock dbg regs (DWT-> LAR = 0xC5ACCE55): The sequence below is resolved for me:

  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->LAR = 0xC5ACCE55; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; 

Answer 2

Not sure if this is identical on STM32F7, but how to do it correctly using the CMSIS headers on STM32F4 (should it actually work on any Cortex-M3 / 4 (/ 7?) That this module provides):

 CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; 

You also need to enable the trace module. Caution, the code is not intermittent! In general, you should leave the counter just free to start and accept the snapshot difference for synchronization.

Just make sure your toolchain is not interfering with your code. OpenOCD / gdb does not do this, not sure what about the tools that provide the manual profiling function.

As I emphasized in the comments: Do not use some homebrew definitions for registers. ST (and ARM) provide CMSIS headers for standard peripheral modules (DWT and CoreDebug are actually ARM-IP) that you should use. This includes not using magic numbers, but certain constants / macros.

See the Architecture Reference Guide for more information. Caution: There is also a "Reference Guide to the Level of Architecture Application", which is not what you want.

Answer 3

You are doing everything right, except that you are not enough to unlock access to the DWT register (as Howard pointed out). In your code, it will be something like:

 volatile uint32_t *DWT_CONTROL = (uint32_t *) 0xE0001000; volatile uint32_t *DWT_CYCCNT = (uint32_t *) 0xE0001004; volatile uint32_t *DEMCR = (uint32_t *) 0xE000EDFC; volatile uint32_t *LAR = (uint32_t *) 0xE0001FB0; // <-- added lock access register *DEMCR = *DEMCR | 0x01000000; // enable trace *LAR = 0xC5ACCE55; // <-- added unlock access to DWT (ITM, etc.)registers *DWT_CYCCNT = 0; // clear DWT cycle counter *DWT_CONTROL = *DWT_CONTROL | 1; // enable DWT cycle counter 

Please note that, as indicated in the ARMv7-M Architecture Reference Guide, the locking mechanism applies only to access to the software. Access to DAP is always allowed (why you can enable the loop counter using a debugger).

Note that the STM32F7 documentation and the ARM documentation have a typo and specify 0xE0000FB0 as the address of the Lock access register (see here ). Using the provided CMSIS register definitions (core_cm7.h), you could avoid this problem since they are correct and, of course, would be more efficient as Olaf said;)