Matter fabric commission issue on XIAO nRF54L15

Products & Technology XIAO
, ,
1

Hello everyone,

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.

2

Hi there,

And welcome here…

SO I see this on the Nordic DevZone too. Same log or identical. :grin:

I: 143789 [FS]GeneralCommissioning: Received ArmFailSafe (0s)
I: 143795 [FS]Fail-safe timer expired
...
E: 143849 [SVR]Failsafe timer expired
E: 143875 [SVR]Commissioning failed (attempt 1): 32
...
E: 143925 [ZCL]OpCreds: Got FailSafeTimerExpired

Key points:

  • 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:

  1. Commissioner starts commissioning, gets to the GeneralCommissioning / OpCreds step.
  2. Something (credentials, timing, or CASE/session flow) goes wrong; commissioner gives up.
  3. Commissioner sends ArmFailSafe(0) to tear the failsafe down.
  4. 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.

    1. 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).
  1. 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.

HTH
GL :slight_smile: PJ :v: