TPIU: LAR and FFCR not part of ARMv7-M standard

[tmplt]

cortex-m/src/peripheral/tpiu.rs

Lines 10 to 34 in 92552c7

	/// Register block
	#[repr(C)]
	pub struct RegisterBlock {
	/// Supported Parallel Port Sizes
	pub sspsr: RO<u32>,
	/// Current Parallel Port Size
	pub cspsr: RW<u32>,
	reserved0: [u32; 2],
	/// Asynchronous Clock Prescaler
	pub acpr: RW<u32>,
	reserved1: [u32; 55],
	/// Selected Pin Control
	pub sppr: RW<Sppr>,
	reserved2: [u32; 132],
	/// Formatter and Flush Control
	pub ffcr: RW<Ffcr>,
	reserved3: [u32; 810],
	/// Lock Access
	pub lar: WO<u32>,
	/// Lock Status
	pub lsr: RO<u32>,
	reserved4: [u32; 4],
	/// TPIU Type
	pub _type: RO<Type>,
	}

c.f. https://developer.arm.com/documentation/ddi0403/d/Debug-Architecture/ARMv7-M-Debug/Trace-Port-Interface-Unit/TPIU-registers-summary

Both lar and ffcr introduced in c6ed9ef. lar is unused, but ffcr utilized in 720282f and refactored in fb604a7.

LAR is likely a part of the CoreSight standard, unsure about FFCR 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.

[tmplt]

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

[tmplt]

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.

[tmplt]

FFCR is also a part of the Cortex-M7 platform.

[tmplt]

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.