OpenThread Sleepy end device failure

[Amadeus]

Hello,

I am currently running the openthread client example provided in the NCS and I am trying to toggle the client as a sleepy end device. However, in the toggle_minimal_sleepy_end_device() function, otThreadSetLinkMode(instance, mode) returns OT_ERROR_INVALID_ARGS and "Failed to set MLE link mode configuration" is thus logged to the console. I have added

CONFIG_OPENTHREAD_MTD=y

CONFIG_OPENTHREAD_MTD_SED=y

in the prj.conf file as explained in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_thread_configuring.html, and the client is correctly initialized as an MTD (child) and does not become either thread leader or router.

I have also the same with the server example, but the same thing happens there as well when calling toggle_minimal_sleepy_end_device().

For the record, the instance pointer returned from openthread_get_default_instance() in toggle_minimal_sleepy_end_device() is not NULL, and the booleans in the mode bit field returned from otThreadGetLinkMode(instance) evaluates to true, false, true, true - respectively. Thus, mode.mDeviceType indicates that the "sender" is an FTD, which i reckon is the problem here. 

Is there anything else I need to do regarding the configuring?

And there is one more thing: When adding the two prj.config lines shown above, the client is not able to send unicast messages to the server. Multicast works as before. That is, I am able to provision the device as before, receiving the IPv6 address of the server, but when trying to send a message, the device halts and needs a restart. Why is this?

[Edvin]

Hello Ernst,

I am terribly sorry for the late reply. Are you still struggling with this?

Let me see if I get this right:

toggle_minimal_sleepy_end_device() returns OT_ERROR_INVALID_ARGS.

 

and the booleans in the mode bit field returned from otThreadGetLinkMode(instance) evaluates to true, false, true, true - respectively. Thus, mode.mDeviceType indicates that the "sender" is an FTD, which i reckon is the problem here. 

 What do you mean by "the sender"? Is this the device that you are trying to put in sleepy end mode? Can you clarify what otThreadGetLinkmode returns? instance is the type otInstance, right? What parameters are "true, false, true, true"?

[Amadeus]

Hello Edvin,

See attachment below.

This function is correctly submitted to the work queue and called when enabling CONFIG_OPENTHREAD_MTD_SED. However, the if statement on line 231 evaluates to true because otThreadSetLinkMode() returns OT_ERROR_INVALID_ARGS. 

See attachment below for declaration of otLinkModeConfig struct returned from otThreadGetLinkMode() on line 222:

The fields of this struct are true, false, true, true (1, 0, 1, 1) when passed to otThreadSetLinkMode(). I reckon the third field, bool mDeviceType, should be false?

[Edvin]

Hello,

I spoke with the our OpenThread team. They say that this seems strange. What HW are you running this on? 

Where do you call toggle_minimal_sleepy_end_device() from? And how often/fast do you call it? In case it is on a button press, may it be that it is being called many times, due to a bounce?

What NCS version are you using? 1.3.0? Is there some way for us to reproduce this on a DK? Is it possible to send a project that will reproduce this?

Best regards,

Edvin

[Amadeus]

Hello,

I am using the nRF52840 DK. I call coap_client_toggle_minimal_sleepy_end_device() with a button press which submits the toggle_MTD_SED_work struct to the work queue. This struct is bounded to toggle_minimal_sleepy_end_device() in an init function. The function is called only once per button click; I have checked this.

I am using the latest version on the master branch; updated the repo yesterday. Still getting the same error.

Yes, I can send the project which produces this error. How do we proceed?

[Edvin]

Hello,

So I tested the unmodified coap_client example from NCS, and at first I also saw the "Failed to set MLE link mode configuration", but I did an nrfjprog --eraseall, and the issue went away.

Can you please test this? If that doesn't work, I am running on NCS v1.3.0, can you please test that tag? The master may or may not work, based on when you fetched it.

Best regards,

Edvin

[Amadeus]

Hello,

Indeed, it looks like the SED call succeeds on tag v.1.3.0. It still fails the latest release of the master branch. Do you know how the power management is handled for the SED's on tag v1.3.0 compared to the latest release? The toggle_minimal_sleepy_end_device() function is updated with power management features on the master branch.

[Amadeus]

I tried on the latest master branch again, and at it looks like the MTD is entering sleep mode. At least, no mesh link error occurs. However, it is not obvious to me how the poll period and communication with the SED works. I am not able to communicate with the SED with multicast messages, which is sort of expected. My understanding is that the SED needs to poll its parent for data, but I am not aware of how this is done. Do you have any details on this?