logging: backend: swo: add Kconfig option for SWO protocol

The TPIU supports serializing the data stream both using an UART-like NRZ
protocol as well as using Manchester encoding. Using Manchester encoding
has the advantage that it enables receivers that support it to recover the
clock from the SWO signal itself. This is particularly useful in situations
where the clock rate changes dynamically or is unknown (for example when
debugging the clock tree setup or working with a device with a misbehaving
main oscillator).

Add a Kconfig choice to switch the protocol, keeping the current default of
using the NRZ encoding.

Signed-off-by: Florian Larysch <[email protected]>

Author: florolf

subsys/logging/backends/Kconfig.swo

@@ -35,6 +35,24 @@ config LOG_BACKEND_SWO_FREQ_HZ
 	  reset. To ensure flawless operation the frequency configured here and
 	  by the SWO viewer program has to match.
 
+choice
+	prompt "SWO protocol"
+	default LOG_BACKEND_SWO_PROTOCOL_NRZ
+
+config LOG_BACKEND_SWO_PROTOCOL_NRZ
+	bool "NRZ encoding"
+	help
+	  Use UART-like NRZ encoding. This is the most common option, but requires the SWO output
+	  frequency to be known on the receiving side.
+
+config LOG_BACKEND_SWO_PROTOCOL_MANCHESTER
+	bool "Manchester encoding"
+	help
+	  Use Manchester encoding. This is less widely supported, but permits the clock to be
+	  recovered automatically on the receiving side.
+
+endchoice
+
 backend = SWO
 backend-str = swo
 source "subsys/logging/Kconfig.template.log_format_config"

subsys/logging/backends/log_backend_swo.c

@@ -100,8 +100,8 @@ static void log_backend_swo_init(struct log_backend const *const backend)
 	ITM->TER  = 0x0;
 	/* Disable ITM */
 	ITM->TCR  = 0x0;
-	/* Select NRZ (UART) encoding protocol */
-	TPI->SPPR = 2;
+	/* Select TPIU encoding protocol */
+	TPI->SPPR = IS_ENABLED(CONFIG_LOG_BACKEND_SWO_PROTOCOL_NRZ) ? 2 : 1;
 	/* Set SWO baud rate prescaler value: SWO_clk = ref_clock/(ACPR + 1) */
 	TPI->ACPR = SWO_FREQ_DIV - 1;
 	/* Enable unprivileged access to ITM stimulus ports */