The xiao nrf54l15 doesn’t have external flash, so getting the nrf connect matter apps working can be a bit tricky. Here is a fairly simple recipe to get the template app working. This recipe turns off the features that use external flash. This might be a good starting point for a hobbyist that doesn’t need these security features, or others waiting for the compressed partition scheme that uses internal flash
I also have an ulterior motive. There seems to be a start up bus fault that this app can reproduce. It might be blocking others, so I wanted to make others aware. Details further below.
Recipe:
Nrf connect and tool chain 3.1.1
Clone platform-seeedboards and configure nrf connect as described in the getting started tutorial.
Create the template app in nrf connect
Modify/add prj.conf with the parameters below
Add xiao_nrf54l15_nrf54l15_cpuapp.overlay to the boards subdirectory with the contents below
Create a build definition. Select “no sysbuild”
Flash your xiao nrf54l15
At this point you should be able to add the device to Apple Home or your favorite eco system.
prj.conf modifications/additions
# Disable Factory Data feature
CONFIG_CHIP_FACTORY_DATA=n
CONFIG_CHIP_FACTORY_DATA_BUILD=n
# Turn off MCU Boot.
CONFIG_CHIP_BOOTLOADER_NONE=y
CONFIG_BOOTLOADER_MCUBOOT=n
CONFIG_CHIP_OTA_REQUESTOR=n
xiao_nrf54l15_nrf54l15_cpuapp.overlay contents
/* If not disabled, the device fails to boot. */
&uart21 {
status = "disabled";
};
The issue I see is if uart21 is left enabled, the device will fail to boot. I was also able to reproduce with the blinky app, however, more debug config needed to be enabled. This might be issue with stack sizing and logging as discussed in this thread Bus faults with xiao nrf54l15?. However, in this case I seem to reproduce it with near default sample app configuration. If this is a true issue, it might be tripping up others as well.
So it turns out ah’ it’s not a bug but an “Undocumented enhancement”…
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.
I checked the defaults in the current board files. The board files set the defaults already as you describe except for disabling of uart21, so the recipe should work as is. The one exception to the defaults is zephyr bt-mon-uart = &uart20, however, my understanding is you only need that if your using something like BT HCI.
Hopefully uart21 gets disabled in the next release of the board files; otherwise, this will trip people up. Is there a way to communicate this to the Seeed team?
PJ 
