Matter Light Switch Sample - Kernel panic

[Tonyll]

I have the matter light switch sample, SDK 3.4.0, on the nRF52840 Dev Kit. I can bind it with a light using Home Assistant (Ikea light) and it works OK. However after a while, or if I just power the dev kit down and up again I get the following from the serial output

 

I: 302 [IN]CASE Server enabling CASE session setups

D: 307 [IN]SecureSession[0x2000fb28]: Allocated Type:2 LSID:40469

I: 313 [SVR]Server Listening...

I: 316 [DL]Device Configuration:

I: 319 [DL]  Serial Number: 11223344556677889900

I: 323 [DL]  Vendor Id: 65521 (0xFFF1)

I: 327 [DL]  Product Id: 32772 (0x8004)

I: 330 [DL]  Product Name: Matter Light Switch

I: 334 [DL]  Hardware Version: 0

I: 337 [DL]  Setup Pin Code (0 for UNKNOWN/ERROR): 20202021

I: 342 [DL]  Setup Discriminator (0xFFFF for UNKNOWN/ERROR): 3840 (0xF00)

I: 349 [DL]  Manufacturing Date: 2022-01-01

I: 353 [DL]  Device Type: 65535 (0xFFFF)

I: 356 [SVR]SetupQRCode: [MT:4CT9142C00KA0648G00]

I: 361 [SVR]Copy/paste the below URL in a browser to see the QR Code:

I: 367 [SVR]project-chip.github.io/.../qrcode.html

I: 375 [SVR]Manual pairing code: [34970112332]

I: Initialize binding Handler

D: 383 [DIS]OperationalSessionSetup[2:00000000000000F9]: State change 1 --> 2

D: 389 [DIS]OperationalSessionSetup[2:00000000000000F9]: State change 2 --> 1

E: 396 [SVR]Failed to establish connection to node 0x00000000000000F9

I: Binding Table size: [1]:

I: [0] UNICAST:

abort()

E: r0/a1:  0x00000004  r1/a2:  0x000b4014  r2/a3:  0x00000000

E: r3/a4:  0x00000004 r12/ip:  0x20011a50 r14/lr:  0x0001cb45

E:  xpsr:  0x210f0000

E: Faulting instruction address (r15/pc): 0x0001cb54

E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0

E: Current thread: 0x20008758 (CHIP)

E: Halting system

The node of the Light is "F9" as in the output. The light is working and can be controlled from Home Assistant. Resetting the dev kit makes no difference.

I saw from a previous posting on the same subject that increasing the size of CONFIG_OPENTHREAD_THREAD_STACK_SIZE might help. I have tried doubling this to 8192 but there is no difference. I have also tried a nanoleaf light with the same result.

[Maria Gilje]

Hello,

E: Faulting instruction address (r15/pc): 0x0001cb54

Could you please follow the Addr2line method described in nRF Connect SDK Intermediate Lesson 2 to find out exactly where the fatal error occurs? 

Best regards,

Maria

[Tonyll]

Hi,

The output of addr2line is - C:/ncs/v3.4.0/zephyr/lib/libc/common/source/stdlib/abort.c:14

I found the addr2line doesn't run from nRF Connect as given in Lesson 2, (vscode for windows with sdk 3.4.0 installed, I needed to find the program in the toolchain directory and run

c:\ncs\toolchains\dcbdc366a1\opt\zephyr-sdk\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-addr2line  -e build_dk/light_switch/zephyr/zephyr.elf 0x0001cb54

Also the zephyr.elf file is in a sub directory of the build folder under the project name (different from Lesson 2)

Best regards

Tony

[Tonyll]

Any feedback from my addr2line information?

Regards

Tony

[Tonyll]

Please can someone respond to my enquiry

Regards

Tony

[Maria Gilje]

Hi Tony, 

My apologies for the delay. We currently have reduced staffing due to summer holidays. 

The code is aborted when printing the information for the bound device, that is here: https://github.com/nrfconnect/sdk-nrf/blob/v3.4.0/samples/matter/common/src/binding/binding_handler.cpp#L123-L129. Preliminary investigation suggests that this is because the switch has no cluster ID saved for the light in the binding table. I will forward this finding internally to get a second opinion on this issue. 

Tonyll said:

I found the addr2line doesn't run from nRF Connect as given in Lesson 2, (vscode for windows with sdk 3.4.0 installed, I needed to find the program in the toolchain directory and run

c:\ncs\toolchains\dcbdc366a1\opt\zephyr-sdk\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-addr2line  -e build_dk/light_switch/zephyr/zephyr.elf 0x0001cb54

Also the zephyr.elf file is in a sub directory of the build folder under the project name (different from Lesson 2)

The specific method is described in more detail in exercise 2, but I do notice that the path in the exercise is missing the "gnu" directory. I'll report this internally. 

Best regards,

Maria

[Tonyll]

Thanks Maria,

Do you have a solution or a work around that I can use to get a working device?

Thanks Tony

[Maria Gilje]

Hi Tony, 

I have not been able to reproduce this issue, but what I have asked for verification on if it is a possible fix, is to use .ValueOr() instead of .value() on the clusterId here.

Best regards,

Maria

[Tonyll]

Hi Maria

I've made some progress from the information you sent.

If I comment-out the call to print the binding table (in binding_handler.cpp) then the error doesn't occur. I couldn't get the compiler to recognise .ValueOr().

Also I checked the binding process using Home Assistant.

HA allows binding to all eligible clusters. This works initially but fails wnen the board is reset and the binding table print is called. Works find if the print binding table is not called.

If only the on/off cluster (06) is specified with HA then the print binding table works OK.

Obviously binding to more than one cluster needs to be possible so the print binding table does need to be able to handle this.

Regards

Tony

[Maria Gilje]

Hi Tony, 

Thank you for sharing your status. Do you know which Matter version HA and the light are using? nRF Connect SDK v3.4.0 is using Matter v1.5.0, so I want to check if there is some incompatibility there. 

Best regards,

Maria

[Tonyll]

Hi Maria,

HA's Matter Server which creates the bindings and allows all relevant clusters to be bound with one command is using "matter.js" (https://github.com/matter-js/matter.js) and is based on Matter 1.5.1

The work around at the moment is to not use the "all relevant" option but to create two bindings, one for onoff and one for level. The sample app works fine with the "all relevant" binding option and controls the light for both onoff and level, it is only when the "print binding table" gets called that the fault occurs.

Best regards

Tony

[Tonyll]

Hi Maria,

I have looked further into the Matter 1.5 standard.

My understanding is that a binding can exist which specifies the end node (or group) without giving a cluster number. The binding node app will then be able to control any available cluster on the end node or group.

The image shows an example given in the Matter spec where a group is specified but the nodes and clusters are omitted.

The HA Matter server creates a single binding table where the controlling node and end node are included but the cluster number is omitted. I thank this is correct but is why the "print binding table" function fails becaue it expects a cluster number.

Best regards

Tony

[Maria Gilje]

Hi Tony, 

Thank you for checking that the Matter versions matched. 

Our developers confirmed that the binding table printing has a bug and they will prepare a bugfix. It will not be patched into NCS, but the relevant commit can be applied manually. In essence, the fix includes verifying that entry.clusterId.HasValue() is true before trying to fetch the ID. 

Thank you for bringing this to our attention.

Best regards,

Maria