Search code examples
debuggingarmstm32stm32f7

STM32 - Dangers of using Data Watchpoint and Trace (DWT)

Looking at the code that is required to initialize Data Watchpoint and Trace (DWT) on STM32F7: 

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

Especially this line to unlock access to DWT register:

DWT->LAR = 0xC5ACCE55;

It resembles switching a safety catch before pulling the trigger. Like getting access to some dangerous action.

At the same time, looking in the documentation I didn't find any dark sides of using DWT. So

Why this explicit set of 0xC5ACCE55 is required here (not like for the other subsystems)? Is there any drawbacks? Dangers? Or something that is really need this safety catch?

P.S. I'm using DWT to access DWT->CYCCNT for performance profiling.

Solution

  • The CoreSight docs provide some info on the need for the lock and possible dangers from not using it.
    That info is copied below.

    In the copied text (below), it says that this lock feature is deprecated starting in CoreSight v3.
    Further down in that doc (not copied here) there is info on the LSR and LAR registers, including a bit that specifies whether "a Software lock mechanism is implemented". Perhaps that bit indicates whether the lock feature is depricated?
    I could not find info on how to determine my MCU's CoreSight version.
    This post has discussion on which MCUs have the lock feature:
    https://community.st.com/s/question/0D50X0000AIeZvnSQF/help-what-is-going-on-

    From, "ARM® CoreSight™ Architecture Specification v3.0":

    B2.3.10 LSR and LAR, Software Lock Status Register and Software Lock Access Register

    *Purpose

    The Software lock mechanism prevents accidental access to the registers of CoreSight components. Software that is being debugged might accidentally write to memory used by CoreSight components. Accidental accesses might disable those components, making the software impossible to debug. The CoreSight programmers’ model includes a Lock Status Register LSR, and a Lock Access Register, LAR, to control software access to CoreSight components to ensure that the likelihood of accidental access to CoreSight components is small.

    Note From CoreSight version 3.0 onwards, implementation of the Software lock mechanism that is controlled by LAR and LSR is deprecated.

    To ensure that the software being debugged can never access an unlocked CoreSight component, a software monitor that accesses debug registers must unlock the component before accessing any registers, and lock the component again before exiting the monitor.

    ARM recommends that external accesses from a debugger are not subject to the Software lock, and therefore that external reads of the LSR return zero. For information on how CoreSight components can distinguish between external and internal accesses, see Debug APB interface memory map on page D2-116.

    A system can include several bus masters capable of accessing the same CoreSight component, for example in systems that include several processors. In this case, it is possible for software running on one processor, processor A, to accidentally access the component while it is being programmed by a debug monitor running on another processor, processor B. Because the component that is being accessed cannot distinguish between the two processors, processor A might disable the component and cause problems for processor B. The probability of this occurring is low, but must be considered if there are special circumstances that make this scenario more likely.*