TC-CNET-4.10 Test step 11 timeout.

[hoorii-zzy]

Hi,

      Our product is about to undergo Matter certification. However, in the testing of TC-CNET-4.10, during the 11th step " ./chip-tool generalcommissioning arm-fail-safe 0 0 1 0", there is a timeout error indicating that the command is not responding. However, when executing it immediately for the second time, it succeeds. This phenomenon is consistently reproducible. Can you provide any guidance on how to resolve this issue? We are anxious to proceed with the product testing.

      I'm urgently looking forward to your reply.

      Jerry.

      22/8/2023

[Charlie]

Hi Jerry,

What is the version of the NCS sample you are using?

Matter Window covering sample acts as  SSED Thread device. If you see the issue of communication with SSED and use the latest version of NCS, I recommend you try to update to the corresponding newer OTBR which will better work with the SSED. Here you can find it:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/thread/tools.html#ug-thread-tools-tbr

Please execute the same test using the recommended version of OTBR (based on a specific NCS version your sample is based on).

Best regards,

Charlie

[hoorii-zzy]

Hi Charlie,

Our windowcovering acts as SED ,not SSED,and our ncs version is 2.2.0.By the way ,The NCS and CHIP versions used in our current product are fixed and cannot be easily replaced with other versions. Are there any other methods to troubleshoot this issue?

Thanks!

Jerry

[Charlie]

Hi Jerry,

hoorii-zzy said:

Our windowcovering acts as SED ,not SSED,

The default role of the Window covering sample is SSED, so can you clarify which kind of modification you have made for changing the Thread Device role to SED?

Have you tested the original sample and encountered the same issue?

hoorii-zzy said:

our ncs version is 2.2.0.By the way ,The NCS and CHIP versions used in our current product are fixed and cannot be easily replaced with other versions.

After checking with our development team, I got the feedback that CSL and SSED support is not very mature in v.2.2.0, especially RCP side was fixed a couple of times since then. If you have considered FW update feature for your product, adapting it to the latest NCS version should be considered.

Best regards,

Charlie

[hoorii-zzy]

The following is the config I'm using in prj.conf to set device acts as SED:

CONFIG_OPENTHREAD_MTD=y

CONFIG_OPENTHREAD_FTD=n

CONFIG_CHIP_ENABLE_SLEEPY_END_DEVICE_SUPPORT=y

# CONFIG_CHIP_THREAD_SSED=y

CONFIG_OPENTHREAD_MTD_SED=y

I haven't tested this use case with the windowcovering demo yet, so I'll give it a try. And our project has a fixed version due to long testing. So it's best not to change the NCS version. So could you please give me other ideas to fix this issue?

Thanks!

[Charlie]

For the issue itself, an 802.15.4 pcap sniffer file and Thread networkkey form that test steps can help to analyze the causes.

[hoorii-zzy]

OK, I will use sniffer try to catch the packet .Could you help me test this case with demo too?

[Charlie]

Hi Jerry,

We can confirm that window covering as SED will work on 2.4.0.

Setting up the test the same as yours will take time and maybe unnecessary as long as we can see debug files collected from your test results.

Best regards,

Charlie

[Charlie]

Sharing config in the build directory: build/zephyr/.config will help us to understand the actual configuration of the device. If it is nRF5340 SoC please also ask for the config file from /build/multiprotocol_rpmsg/zephyr/.conf.

Best regards,

Charlie