查看在STM32F7上初始化数据观察点和跟踪（DWT）所需的代码：
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->LAR = 0xC5ACCE55;
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;特别是这一行解锁对DWT寄存器的访问：
DWT->LAR = 0xC5ACCE55;它就像在扣动扳机之前切换一个安全掣。就像获得一些危险行动的通道。
同时，在文档中我没有发现使用DWT的任何阴暗面。
为什么这里需要这个显式的0xC5ACCE55集合（不像其他子系统）？有什么缺点吗？危险吗？或者确实需要这个安全锁吗？
P.S.我正在使用DWT访问DWT->CYCCNT以进行性能分析。
1条答案
按热度按时间neekobn81#
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
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.*