Deinit Thread in the dynamic multiprotocol example.

[Yarosalv]

Hello, fellow developers!

Right now I'm trying to decrease the current consumption of my BLE/Thread Node witch is build on the nRF52840 dongle. It is crucial for me not to lose BLE connections,

thus I cannot use switched multiprotocol. My idea is to stay at BLE for the most time and use Thread only for a short period (assuming that during this period I still can 

handle BLE connections).

I've found two possible functions for this. Both of them clear the instance of OpenThread and the first one deinitialize drivers as well.

void thread_deinit(void)
{
    ASSERT(mp_ot_instance != NULL);

    otInstanceFinalize(mp_ot_instance);
    otSysDeinit();
    mp_ot_instance = NULL;
}

void thread_soft_deinit(void)
{
    ASSERT(mp_ot_instance != NULL);

    otInstanceFinalize(mp_ot_instance);
    mp_ot_instance = NULL;
}

I assume I should use thread_soft_deinit() and reinitialize thread instance when I want to have Thread up and running. Unfortunately, thread_instance_init() does all from scratch

(including thread drivers) and there is no functionality for thread instance only initialization.

Is there any possible way to solve this issue? Thx in advance.

[Charlie]

Hi Yaroslav,

After I read your needs, my first impression is that Dynamic multiprotocol maybe more fit your needs, but you are using the Switched multiprotocol method. This method will break the BLE connection for a few seconds when handling OpenThread protocol.

For the thread deinitialize issue, Switched multiprotocol examples introduction page has a warning that may be the cause, it also provides a solution:

There is an issue in the nRF5 SDK for Thread and Zigbee v4.1.0 that causes higher-than-usual sleep power consumption for all multiprotocol examples when using nRF52840. See workaround on DevZon

Please try and see if it helps.

Best regards,

Charlie

[Yarosalv]

Hi Charlie! Thank you for your reply!

I've checked thees examples and the deinitialization routine still giving me a hard time. Now I'm testing Switched Multiprotocol. The numbers look pretty good but still confuses me. At the start of the program during the BLE phase, everything looks good - we are advertising and the CPU goes to sleep. But after the Thread phase consumption stays at 3.5 mA and I can't understand why. This is a bare example with no modifications. Please, look at the graph I've got:

[Charlie]

For this test, can you double-check you have implemented the solution mentioned in workaround on DevZon? because this sounds like exactly same issue. 

[Yarosalv]

Hi Charlie! Sorry for the long reply. I've caught covid and was unavailable. 

Yes, your advice helped, thank you! I only want to mention, that I've been using SDK 4.0 and didn't utilize the SED mechanic. The issue pops up after Thread deinit, not the sleep mode. Maybe you would want to check it and modify the post with a workaround.