Matter Device Commissioning – STM32WB5MM-DK & NUCLEO-WB55RG Unable to Join Thread Network

[AkihiroN]

I am developing a Matter device (Thread) using the STM32WB5MM-DK and NUCLEO-WB55RG.

When commissioning the device using the Google Home app on a Google Nest Hub:

The first STM32WB5MM-DK was successfully commissioned.
However, the second STM32WB5MM-DK failed to join the Thread Network.
I encountered the same issue when using NUCLEO-WB55RG.
I have attached the error logs for reference.

To troubleshoot the issue, I modified the Device Attestation Certificate (DAC) in the firmware and tested commissioning again:

NUCLEO-WB55RG was successfully commissioned with the modified DAC.
However, STM32WB5MM-DK still failed, even with the modified DAC.

Questions:
Is it expected behavior that the ability to join the Thread Network depends on the DAC when commissioning with a Google Nest Hub?
Why does changing the DAC allow NUCLEO-WB55RG to join the Thread Network, but not STM32WB5MM-DK?
Could there be differences in how the Google Home app or Google Nest Hub handles DAC validation for different hardware?
What specific checks does the Google Home app or Google Nest Hub perform regarding the DAC?
Can you confirm if the same issue occurs on your side?
I am using the following repositories for testing:

NUCLEO-WB55RG: https://github.com/stm32-hotspot/stm32wb-matter-device-over-thread
STM32WB5MM-DK: https://www.st.com/ja/embedded-software/x-cube-matter.html

Any insights or guidance would be greatly appreciated.
Thank you in advance!

[Ouadi]

Hi @AkihiroN,

After analyzing the provided logs, it seems that the device fails to find an operational thread network, even after scanning all the channels, the issue looks related to thread network stability and not to Data factory parameters.

Please note that the data factory management is done using the flag CONFIG_STM32_FACTORY_DATA_ENABLE set to 0 for test meaning that Matter test VID/PID & certificates will be used at commissioning time.

From the logs, I see that you are using a very old version of X-Cube-Matter V 1.0.3, so as a first step I suggest to update the version to the latest one v1.1.1 and make sure to update the STM32WB M0 firmware as well.

Since this version, there have been some improvements linked to radio robustness that may solve your issue.

Also, please make sure to put the device close to the Google Nest for the commissioning phase.

I hope this helps.

Best regards, Ouadi

[AkihiroN]

Hello, @Ouadi 

Thank you for your confirmation.
Yes, I too believe that it may be a threading network issue, not a data factory parameter.
What I think is the problem is that this problem occurs on the second STM32WB5MM-DK, while the first STM32WB5MM-DK can be commissioned successfully without this problem.
Also, both NUCLEO-WB55RGs were successfully commissioned by changing the first DAC and the second DAC.
With STM32WB5MM-DK, this problem occurs even if the second DAC is changed.

I will also attach the logs, but this problem still occurs even with the latest X-Cube-Matter v1.1.1.
This problem occurs only in the Google environment and not in the Apple or Amazon platforms.

Is there any solution to this problem?

Translated with DeepL.com (free version)

[Ouadi]

Hello,

Is this problem occurs only with the same STM32WB5MM-DK board ? As you mentioned, the commissioning is successful with the first STM32WB5MM-DK board and Nucelos. So it may be linked to this specific board, Can you try to commission with a third board to confirm ?

Have you done a full chip erase + external flash memory erase before testing ?

Regards,

Ouadi

[AkihiroN]

Hello, @Ouadi 

Thank you for your confirmation.
Yes, it is occurring on the second STM32WB5MM-DK.
I also thought it might be dependent on the board, so I tried it on a third STM32WB5MM-DK, but it didn't work.

I have erased the Flash and NOR Flash before testing.

Thank you for your confirmation.

[Ouadi]

Hi,

Can you describe the network environnement ? Do you have many connected devices ? which protocols ? 

Do you power off the other devices for test ? The idea is to know if this is related to the radio interference that may disturb the commissioning, and to identify the root cause.

Other point, for other boards, the commissioning is always successful ? If yes, can you provide the logs ? 

Best regards,

Ouadi

[AkihiroN]

Hello, @Ouadi 
Thank you for confirming.

No other devices are connected to anything else.

Also, what are the other boards?
The first STM32WB5MM-DK and NUCLEO-WB55RG can be commissioned successfully, respectively.