i ran into an issue with XIAO nRF54L15 while building a matter app.
This is happening no matter if i’m running a sample or my own project.
So the device boot’s as expected , then i’m using the companion app to comission the devie onto the thread/matter network , the device get’s comissioned into the thread network but fails to get comissioned into the matter fabric with following error:
I: 143789 [FS]GeneralCommissioning: Received ArmFailSafe (0s)
I: 143795 [FS]Fail-safe timer expired
I: 143799 [EM]<<< [E:27312r S:17799 M:238238144 (Ack:64468312)] (S) Msg TX from 0000000000000000 to 0:FFFFFFFB00000000 [0000] [UDP:[fd3d:989b:60ee:1:eaa0:2cf7:ceca:1913]:36303] — Type 0001:09 (IM:InvokeCommandResponse) (B:70)
I: 143819 [EM]??1 [E:27312r S:17799 M:238238144] (S) Msg Retransmission to 0:FFFFFFFB00000000 scheduled for 2340ms from now [State:Active II:500 AI:300 AT:4000]
I: 143834 [EM]>>> [E:27311r S:17799 M:64468313 (Ack:238238143)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] to 0000000000000000 — Type 0000:10 (SecureChannel:StandaloneAck) (B:34)
E: 143849 [SVR]Failsafe timer expired
D: 143853 [IN]SecureSession[0x2000ec88]: MarkForEviction Type:1 LSID:17799
I: 143859 [SC]SecureSession[0x2000ec88, LSID:17799]: State change ‘kActive’ → ‘kPendingEviction’
D: 143868 [IN]SecureSession[0x2000ec88]: Released - Type:1 LSID:17799
E: 143875 [SVR]Commissioning failed (attempt 1): 32
D: 143879 [IN]SecureSession[0x2000ec88]: Allocated Type:1 LSID:17800
This is driving me crazy for the past couple of days. I’m using several XIAO nRF54L15 boards so it’s not the board falut. I don’t know it it’s a timer , cerificate or configuration issue.
ArmFailSafe (0s) – the commissioner (HA / app / chip-tool) is sending an ArmFailSafe command with a timeout of 0 seconds. That’s basically “disarm / close the failsafe right now.”
Immediately after, the device logs “Fail-safe timer expired” and then “Commissioning failed (attempt 1): 32”.
In Matter, error 0x32 is CHIP_ERROR_TIMEOUT on the commissioner side — it’s what you see when the commissioner thinks something took too long or something in the flow didn’t complete properly.
So the flow is roughly:
Commissioner starts commissioning, gets to the GeneralCommissioning / OpCreds step.
Commissioner sends ArmFailSafe(0) to tear the failsafe down.
Device logs “failsafe expired” and “Commissioning failed (attempt 1): 32”.
So yeah — it is a sync/timeout problem between device and commissioner, not a basic Thread issue (since Thread commissioning works).
2. Why it works on nRF52840 DK but not on XIAO nRF54L15
That’s the interesting part: same Matter sample on 52840 DK commissions fine, but XIAO 54L15 fails at the fabric stage.
That screams “board-specific config”, not “your certs are totally wrong”, especially because Nordic explicitly says the thermostat sample already uses the default test certs and you usually don’t need to touch them.Nordic DevZone+1
Given what’s known about the XIAO nRF54L15 so far:
There are already known quirks around XIAO board config vs Nordic DK, including UART21 and bus faults, stack/logging issues, etc.Seeed Studio Forum+1
Seeed’s Matter recipe for XIAO 54L15 requires specific board-root files, sysbuild/MCUboot configs, and a fixed SDK version (3.0.2).Seeed Studio
So I’d treat this as “timers / clocks / Kconfig / board-root aren’t exactly right on the XIAO build.”
3. The big suspects I’d point out
So the failsafe will be instantly, if the the timer isn’t config’d correctly.
Controller / Matter stack – your log shows ArmFailSafe (0s) then “Fail-safe timer expired”. That means the commissioner asked for a 0-second failsafe, so it expires immediately. That’s usually a controller-side issue (HA, chip-tool, ecosystem bug, or timing issue on the Thread/Matter side).
Board target / certificates / factory data – make sure you’re building the thermostat sample for the correct board target (xiao_nrf54l15/...), and that you haven’t accidentally overridden the default test certificates or factory data for that sample.
To test a 30-second fail-safe you’d do it from the controller (e.g. chip-tool): ./chip-tool generalcommissioning arm-fail-safe 30 0 1 0.
I’m trying to solve this issue but help others which may run into this kind of issues.
So it seems that there are different unrelated issues around this little board.
One is regarding lfxo and hfxo capacitors in xiao_nrf54l15_nrf54l15_cpuapp.dts - solved that one
The other one seems to be wih “west flash” command which is not always writing certificates to factory_data partition → I’m getting strange behaviour here.
The last one is with the cerificates
For example (for thermostat sample):
If i’m changing the app name from thermostat to anythig else and run it on xiao_nef54l15_nrf54l15 it will fail on commissioning
If i’m changing (in prj.conf) device name, manufacturer name, serial of the device, password and I run the app on an nRF52840DK it just works and get’s commissioned
If i’m changing any of those informations and run the same app on xiao_nef54l15_nrf54l15 it will fail on matter fabric commissionig - same error as above.
So i’m suspecting it has to be related to the certificates and the way they are included in the build. There is some configuration i’m missing ? (If it works for nordic board and not for this one it has to be in the config ! but what ?)
I would like to know if someone has managed to run a matter app on Xiao nrf54l15 with a different app name at least .
I’m back on this issue with some guides for people getting in this spot.
So after 2 weeks and 200 - 300 builds / flash (or maybe more) i have manged to solve all the issues.
DON”T TRUST THE TOOLS - the first issue that set the failsafe timer to 0 ( “[FS]GeneralCommissioning: Received ArmFailSafe (0s)“ ) was because of ZAP tool that was changing some variables to null when opening and saving the *.zap file. One of those was the Breadcrumbs inside Commissionig which was initialised to null and led to that error
CHECK ALL CONFIG SOURCES - inside zephyr there are 3 configuration sources (or maybe more - i only found only 3 so far ): *.conf files, Kconfig + Kconfig.sysbuild and cmake build arguments. Before doing any king of configuraton go through these files and see and understand what’s in there (failing to do so may give unexpected results). On nRF matter samples inside Kconfig.sysbuild they have enbled generating factory data (config MATTER_FACTORY_DATA_GENERATE default y) which is equivalent to -DSB_CONFIG_MATTER_FACTORY_DATA_GENERATE and SB_CONFIG_MATTER_FACTORY_DATA_GENERATE
CHECK AND UNDERSTANF board configuration files cause you can also get some unwated values in there which also lead to unexpected results
No i can finally go and do some supply current testing and maybe hack the XIAO nRF54L15 board to save some uAmps.
PJ 