Open tmplt opened 2 years ago
old openocd debug notes regarding FFCR
:
TPIU_FFCR
, Formatter and Flush Control Register. See ARM Cortex-M4 Processor Technical Reference Manual, rev. r0p1, p. 95:
Clears EnFCont
: disables continuous formatting. That is, bypasses a formatter: only ITM, DWT packets is passed through. ETM packets are discarded.
Debug: 865 8837287 hla_target.c:768 adapter_read_memory(): adapter_read_memory 0xe0040304 4 1
Debug: 866 8837287 target.c:2394 target_read_u32(): address: 0xe0040304, value: 0x00000102
Debug: 867 8837287 target.c:2482 target_write_u32(): address: 0xe0040304, value: 0x00000100
Debug: 868 8837287 hla_target.c:783 adapter_write_memory(): adapter_write_memory 0xe0040304 4 1
FFCR
is part of the Cortex-M4 platform. I do not know what other Cortex-M platforms support it, but a cm4
feature gate should be added.
LAR
(and LSR
) are CoreSight managenment registers. LSR
is RAZ if not implemented so I presume we can sefely use it without a gate.
LAR
and LSR
usage is described in the CoreSight specification, §B2.3.10, pp. 59-61. In summary, check LSR.SLI
and LSR.SLK
whether a software lock is implemented and whether the registers are locked. If locked, write 0xC5ACCE55
(similar to ITM) to LAR
to unlock registers, configure registers, and relock by writing something other than 0xC5ACCE55
to LAR
.
While not part of seemingly any Cortex-M standard, we better implement LAR
and LSR
access to any standard that exposes a TPIU.
https://github.com/rust-embedded/cortex-m/blob/92552c73d3b56dc86007450633950d16ebe0e495/src/peripheral/tpiu.rs#L10-L34
c.f. https://developer.arm.com/documentation/ddi0403/d/Debug-Architecture/ARMv7-M-Debug/Trace-Port-Interface-Unit/TPIU-registers-summary
Both
lar
andffcr
introduced in c6ed9ef.lar
is unused, butffcr
utilized in 720282f and refactored in fb604a7.LAR
is likely a part of the CoreSight standard, unsure aboutFFCR
at the moment. Access to there registers should be gated if backing documentation can be found, otherwise removed.I want to recall figuring
FFCR
out when I debugged openocd for an STM32 last year, but I need to verify that.