XIAO nrf54l15 Matter App Recipe

Products & Technology XIAO
2

Hi there,

So it turns out ah’ it’s not a bug but an “Undocumented enhancement”…:grin:
it’s tripping over UART21 being mapped to pins that collide with the SWD/SWO debug domain on the 54L15. When UART21 is enabled (especially with a debug probe attached / SWO active), the pin clash can wedge early init and look like a “boot failure.” That’s why disabling &uart21 “fixes” it—and why even Blinky can reproduce it with near-default configs.

What’s going on(according to dev Zone)

  • In the upstream board files, xiao_serial is aliased to &uart21 and uart21 is pinned to TX=P2.8, RX=P2.7. On the 54L15, P2.07 is also SWO. If your CMSIS-DAP is alive or SWO gets toggled, you’re fighting the debugger for that pin. Hello, early fault. GitHub+1
  • There are also reports of 54L15 UART framing/instability in certain mappings, which adds fuel when logging is enabled. Nordic DevZone+1

Use UART20 as your console (recommended)

  • UART20 is already pinned to P1.9 (TX) / P1.8 (RX) in the board pinctrl and doesn’t collide with SWO. GitHub
  • Drop this overlay in boards/xiao_nrf54l15_nrf54l15_cpuapp.overlay:
/* Make console/serial use UART20 and hard-disable UART21 to avoid SWO conflict. */
&uart20 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&uart20_default>;
	pinctrl-names = "default";
};

/* Board alias often points xiao_serial -> &uart21; kill it to be safe. */
&uart21 {
	status = "disabled";
};

&{/chosen} {
	zephyr,console = &uart20;
	zephyr,uart-mcumgr = &uart20;
	zephyr,shell-uart = &uart20;
	zephyr,bt-mon-uart = &uart20;
};

No other changes needed; just build for xiao_nrf54l15_nrf54l15_cpuapp.

that and the stack stuff may allow the debugger more room? YMMV
I wonder if the Seedineers map those pins without consultation?

idunno I’m sure if you must use uart21 there’s got to be a way to remap to non-SWO pins… YMMV
well see what others come with too. :+1:

HTH
GL :slight_smile: PJ :v: