• State Verified Answer
  • Replies 12 replies
  • Subscribers 86 subscribers
  • Views 1108 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 354446
Options

Matter app development

ady

Hello,

i;m developing a matter over thread application on a Seeed board XIAO nRF54L15.

Currently the border router is set up on a Nrf52840 Dongle connected to a Rapberry Pi5 running Home Assistant.

The thread network is working fine and has some sensor based on NRf52840 (built without factory data support and they get commissioned into matter fabric without any issues.)

When I build and run the matter thermostat in the sample folder it get's commissioned onto thread but NOT on matter fabric.

..........................................................

(SecureChannel:StandaloneAck) (B:34)
D: 143742 [IN]UDP Message Received packet nb : 30 SrcAddr : fd3d:989b:60ee:1:eaa0:2cf7:ceca:1913[36303] DestAddr : fd3d:989b:60ee:1:131:f0ef:d087:38cc[5540] Payload Length 65
D: 143759 [IN]UDP Message Received packet nb : 31 SrcAddr : fd3d:989b:60ee:1:eaa0:2cf7:ceca:1913[36303] DestAddr : fd3d:989b:60ee:1:131:f0ef:d087:38cc[5540] Payload Length 34
I: 143775 [EM]>>> [E:27312r S:17799 M:64468312] (S) Msg RX from 0:FFFFFFFB00000000 [0000] to 0000000000000000 --- Type 0001:08 (IM:InvokeCommandRequest) (B:65)
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
I: 143887 [DIS]Updating services using commissioning mode 2
D: 143893 [DL]Using Thread extended MAC for hostname.
I: 143897 [DIS]Advertise operational node F26E0A7B3A2D658C-231C1B02605E41C4
D: 143904 [DL]Using Thread extended MAC for hostname.
I: 143909 [DIS]Advertise commission parameter vendorID=65521 productID=32781 discriminator=1361/05 cm=2 cp=0
I: 143919 [DL]advertising srp service: 3DF2A666EA541FCD._matterc._udp
E: 143925 [ZCL]OpCreds: Got FailSafeTimerExpired
E: 143929 [ZCL]OpCreds: Proceeding to FailSafeCleanup on fail-safe expiry!
I: 143936 [TS]Pending Last Known Good Time: 2025-11-14T00:00:00
I: 143941 [TS]Previous Last Known Good Time: 2025-11-14T00:00:00
I: 143947 [TS]Reverted Last Known Good Time to previous value
E: 143953 [DL]Long dispatch time: 104 ms, for event type 32784
I: 143958 [FS]Fail-safe cleanly disarmed
D: 145331 [DL]SRP update succeeded

If i build the same sample for nRF52840DK it get comissioned onto thread and matter fabric.

What is causing this behavior ?

Is this because of the certificate ?

Is there a special way to include test certificates into the build ?

Please point me in the right direction,

Parents
  • 0

    Hi,

    Does the XIAO nRF54L15 have an external 32.768 kHz crystal? If not, you need to set this config:

    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

    Best regards,
    Marte

  • 0 in reply to ady

    Hi,

    From the event log, it seems like you marked the ticket as verified answer, which closed it. When you replied, it was reopened again.

    The thermostat sample should work out of the box, and it should not be necessary to change the certificates. The test certificates are already used by default in the sample.

    What board target are you using when building for the Seeed board XIAO nRF54L15?

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold

    Im building for xiao_nrf54l15/nrf54l15 and everything builds fine but it seems that board type has some issues. Your first suggestion about the oscillator already helped - it seems there was a misconfiguration in xiao_nrf54l15_nrf54l15_cpuapp.dts about capacitors (didn't solved the problem).

    I have been reading this forum for a while and it seems you are the best person to ask for help!

    The test cerificates are bult only for the samples ? For example if i clone a sample and change it's name, the test certificate won't work anymore?

    Or if I build an example with auto-generation of new CD, DAC and PAI certificates  (with chip_cert) the mater commissioning will fail ?  (We should use chip_cert from matter repository or the one from sdk ?)

  • 0 in reply to ady

    Hi

    ady said:
    The test cerificates are bult only for the samples ? For example if i clone a sample and change it's name, the test certificate won't work anymore?

    The samples use pre-generated certificates from matter/credentials/development/attestation (see https://github.com/nrfconnect/sdk-connectedhomeip/tree/master/credentials/development/attestation) that match the configured product ID. Even if you copy a sample and change its name, the test certificate should still work. 

    ady said:
    Or if I build an example with auto-generation of new CD, DAC and PAI certificates  (with chip_cert) the mater commissioning will fail ?  (We should use chip_cert from matter repository or the one from sdk ?)

    If you auto-generate new CD, DAC, and PAI, it should work as well. However, if you are using chip-tool as the commissioner, you need to provide the new certificates to chip-tool. If not, it will try to use the default certificates, and the commissioning will fail.

    I am not sure what you mean by the Matter repository or the SDK, but the certificates used by the samples are from the nRF Connect SDK downstream of the Matter repository, i.e., under matter/credentials/development/attestation.

    I have not tested Matter with Home Assistant, so I am not familiar with how it handles test certificates. However, if you have successfully commissioned the nRF52840 using test certificates, then it should also work with the nRF54L15. If commissioning still fails, can you provide logs from Home Assistant and complete logs from the device? Make sure to do a full erase or factory reset of the device before commissioning.

    Best regards,
    Marte

Reply
  • 0 in reply to ady

    Hi

    ady said:
    The test cerificates are bult only for the samples ? For example if i clone a sample and change it's name, the test certificate won't work anymore?

    The samples use pre-generated certificates from matter/credentials/development/attestation (see https://github.com/nrfconnect/sdk-connectedhomeip/tree/master/credentials/development/attestation) that match the configured product ID. Even if you copy a sample and change its name, the test certificate should still work. 

    ady said:
    Or if I build an example with auto-generation of new CD, DAC and PAI certificates  (with chip_cert) the mater commissioning will fail ?  (We should use chip_cert from matter repository or the one from sdk ?)

    If you auto-generate new CD, DAC, and PAI, it should work as well. However, if you are using chip-tool as the commissioner, you need to provide the new certificates to chip-tool. If not, it will try to use the default certificates, and the commissioning will fail.

    I am not sure what you mean by the Matter repository or the SDK, but the certificates used by the samples are from the nRF Connect SDK downstream of the Matter repository, i.e., under matter/credentials/development/attestation.

    I have not tested Matter with Home Assistant, so I am not familiar with how it handles test certificates. However, if you have successfully commissioned the nRF52840 using test certificates, then it should also work with the nRF54L15. If commissioning still fails, can you provide logs from Home Assistant and complete logs from the device? Make sure to do a full erase or factory reset of the device before commissioning.

    Best regards,
    Marte

Children
  • 0 in reply to Marte Myrvold

    Hello Marte,

    thanks for the suggestions. I have managed to make it work on the default configuration.

    But if I add to prj.conf:

    # Enable building the new factory data
    CONFIG_CHIP_FACTORY_DATA=y
    CONFIG_CHIP_FACTORY_DATA_BUILD=y
    CONFIG_CHIP_FACTORY_DATA_USE_DEFAULT_CERTS=y
    CONFIG_CHIP_FACTORY_DATA_MERGE_WITH_FIRMWARE=y
    CONFIG_CHIP_DEVICE_GENERATE_ROTATING_DEVICE_UID=n
    CONFIG_CHIP_FACTORY_DATA_GENERATE_ONBOARDING_CODES=y
    CONFIG_CHIP_FACTORY_DATA_CERT_SOURCE_GENERATED=y
    CONFIG_CHIP_FACTORY_DATA_GENERATE_CD=y

    # Set up the Factory Data
    CONFIG_CHIP_DEVICE_SERIAL_NUMBER="74269132"
    CONFIG_CHIP_DEVICE_VENDOR_ID=65521
    CONFIG_CHIP_DEVICE_VENDOR_NAME="Nordic Semiconductor ASA"
    CONFIG_CHIP_DEVICE_PRODUCT_ID=32781
    CONFIG_CHIP_DEVICE_PRODUCT_NAME="Environment sensor"
    CONFIG_CHIP_DEVICE_MANUFACTURING_DATE="2025-11-15"
    CONFIG_CHIP_DEVICE_HARDWARE_VERSION=1
    CONFIG_CHIP_DEVICE_HARDWARE_VERSION_STRING="DTS"
    CONFIG_CHIP_DEVICE_DISCRIMINATOR=0x635
    CONFIG_CHIP_DEVICE_SPAKE2_PASSCODE=65286841
    CONFIG_CHIP_DEVICE_SPAKE2_IT=1000
    CONFIG_CHIP_DEVICE_SPAKE2_TEST_VERIFIER="3kX890KClffU+BvLXQm68RDvXWlyuPofi8DEFkv74mQEnC+g02oLJTkItSDLBUvuYX87D1C7SnHZ7PuWvDziO57cHjPgUlkEhlRj+bvWKmE/FEwKuffl+VB7Dlx9HurJwQ=="
    CONFIG_CHIP_DEVICE_ROTATING_DEVICE_UID="1566d6032a898e53f7d58133a19ac9d2"
    CONFIG_CHIP_DEVICE_ENABLE_KEY="449eb9544ee3eef8d9fb7accb514fada"

    SB_CONFIG_MATTER_FACTORY_DATA_GENERATE=y to sysbuild.conf

    I get in the build:

    [11/23] Generating new Factory Data...
    [INFO] Generating SPAKE2+ Verifier...
    [INFO] Generating new Certification Declaration using chip-cert...
    [INFO] Generating new PAI and DAC certificates using chip-cert...
    [INFO] /home/ady/environment_sensor/build/environment_sensor/zephyr/PAI_cert.der
    [INFO] /home/ady/environment_sensor/build/environment_sensor/zephyr/PAI_key.der
    [INFO] /home/ady/environment_sensor/build/environment_sensor/zephyr/DAC_cert.der
    [INFO] /home/ady/environment_sensor/build/environment_sensor/zephyr/DAC_key.der
    [WARNING] KEY password has not been provided. It means that DAC key is not encrypted.
    [INFO] Validating JSON with schema...
    [INFO] Validate OK

    BUT the app fails on boot with

    *** Booting My Application v1.1.1 - unknown commit ***
    *** Using nRF Connect SDK v3.1.1-e2a97fe2578a ***
    *** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
    D: 1025 [DL]Boot reason: 1
    I: 1029 [DL]BLE address: DD:E2:D7:49:45:62
    E: LED index out of the range
    I: 1042 [DL]CHIP task running
    I: Init CHIP stack
    I: 1046 [DL]OpenThread started: OK
    I: 1050 [DL]Setting OpenThread device type to MINIMAL END DEVICE
    E: 1056 [DL]Failed to parse factory data
    E: FactoryDataProvider::Init() failed [Error: 160]
    E: Exited with code a0

  • 0 in reply to ady

    Hi,

    I do not get the same errors when testing your configs on an nRF54L15 DK. Do you have a static partition file for the board, e.g., pm_static_<build_target>.yml? See  Preparing factory data partition on a device for more information.

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold

    Yes, this is the defaul one for this board:

    mcuboot:
    address: 0x0
    region: flash_primary
    size: 0xD000
    mcuboot_pad:
    address: 0xD000
    region: flash_primary
    size: 0x800
    app:
    address: 0xD800
    region: flash_primary
    size: 0xD1800
    mcuboot_primary:
    orig_span: &id001
    - mcuboot_pad
    - app
    span: *id001
    address: 0xD000
    region: flash_primary
    size: 0xD2000
    mcuboot_primary_app:
    orig_span: &id002
    - app
    span: *id002
    address: 0xD800
    region: flash_primary
    size: 0xD1800
    mcuboot_secondary:
    address: 0xDF000
    orig_span: &id003
    - mcuboot_secondary_pad
    - mcuboot_secondary_app
    region: flash_primary
    size: 0x93000
    span: *id003
    mcuboot_secondary_pad:
    address: 0xDF000
    region: flash_primary
    size: 0x800
    mcuboot_secondary_app:
    address: 0xDF800
    region: flash_primary
    size: 0x92800
    factory_data:
    address: 0x172000
    region: flash_primary
    size: 0x1000
    settings_storage:
    address: 0x173000
    region: flash_primary
    size: 0xA000

  • 0 in reply to ady

    Hi,

    The partitions look correct.

    Since you are generating new certificates, can you try setting CONFIG_CHIP_FACTORY_DATA_USE_DEFAULT_CERTS=n in prj.conf to disable the default certificates?

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold

    Hello Marte and thank you for your support.

    I was having multiple issues at the same time and I will leave this here for the people running into same issues. So after 2 weeks and about 300+ builds / flash of different configurations I have managed to solve them.

    1. First error - the matter commissioning error [FS]GeneralCommissioning: Received ArmFailSafe (0s) was because of ZAP tool. On editing the *.zap file the tool initialized some fields to null values and the one that was causing that error was Breadcrumb set to null in General Commissionig.  Conclusion: don't trust the tools  - check the files before and after editing for unwanted changes

    2. There was some "stange values" internal capacitors for lfxo and hfxo on the board files

    3. This is the one made the mcu fail on boot with E: 1056 [DL]Failed to parse factory data and is the strangest one. 

    For all the "newcomers" they should know about multimple comfigurations spread across multiple file types. This will cause a lot of confusion.

    I' m talking here about, for example, SB_CONFIG_MATTER_FACTORY_DATA_GENERATE , config , MATTER_FACTORY_DATA_GENERATE, DSB_CONFIG_MATTER_FACTORY_DATA_GENERATE - they all do the same thing but are located in different files / commands:  (DSB_CONFIG_MATTER_FACTORY_DATA_GENERATE  - argument to west, SB_CONFIG_MATTER_FACTORY_DATA_GENERATE in sysbuild.conf, MATTER_FACTORY_DATA_GENERATE in Kconfig.sysbuild for matter samples).

    The strangest thing was for me that all started to work after i removed CONFIG_CHIP_FACTORY_DATA=y . I can't say I understand why !

Related
Terms of service