Issues with OpenThread and Bluetooth multiprotocol support locking up

[ajlennon]

Hi,

We're working with the nRF52840 DK and Dongle, and also the nRF53840 DK.

I have code based on the nRF Connect v2.4.0 SDK using OpenThread on 802.15.4 connecting to an OTBR implemented with an nRF52840 dongle running the RCP firmware.

I can publish messages successfully and reliably from a modified CLI firmware running on the nRF52840 dongle and also the DK and the nRF53840 DK.

However when I enable multiprotocol support I run in to trouble.

When I am scanning for bluetooth devices with a certain profile (GPS location) alongside the OpenThread support then the code locks up.

However when I run this code on the nRF52840 DK then it is fine.

I've had a look at changing stack sizes and so forth but nothing seems to help.

Can anybody help me understand what I am doing wrong here.

I assume from the documentation that Bluetooth + OpenThread is supposed to be supported with multiprotocol on nrf52840?

Code is here: https://github.com/DynamicDevices/cli/blob/master/src/main.c

Currently Bluetooth is disabled as I say due to the lock up issue: https://github.com/DynamicDevices/cli/blob/d5e3e2341af72098617d8f84380e3b23c38ce5c2/src/main.c#L286

This is quite important for our project which is a large European Space Agency backed 18-month trial.

Thanks!

Alex

[Susheel Nuguru]

One of our OpenThread expert thinks that this could be memory related and also maybe due to the processing power difference (nRF53 has both more processing power and memory).

As a first step you could try to increase the stack sizes and see if any of the memory optimizations tips mentioned here works. If that does not help, please share a minimalistic project for us to reproduce this. 

[ajlennon]

I've tried various things to affect the build and stack size e.g.

```

# Enable OpenThread features set

#CONFIG_OPENTHREAD_MTD=y

CONFIG_OPENTHREAD_FTD=y

#CONFIG_OPENTHREAD_SLAAC=y

# Minimise size

#CONFIG_NET_SOCKETS=n

#CONFIG_OPENTHREAD_SHELL=n

#CONFIG_COAP=n

#CONFIG_COAP_UTILS=n

#CONFIG_OPENTHREAD_COAP=n

#CONFIG_NRF_802154_SER_LOG=y

#CONFIG_ASSERT=y

#CONFIG_ISR_STACK_SIZE=4096

#CONFIG_IDLE_STACK_SIZE=1024

#CONFIG_BT_RX_STACK_SIZE=4096

#CONFIG_SHELL_STACK_SIZE=8192

#CONFIG_NET_RX_STACK_SIZE=4096

#CONFIG_NET_TX_STACK_SIZE=4096

#CONFIG_MPSL_WORK_STACK_SIZE=4096

#CONFIG_PRIVILEGED_STACK_SIZE=2048

#CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192

#CONFIG_OPENTHREAD_RADIO_WORKQUEUE_STACK_SIZE=4096

#CONFIG_IPC_SERVICE_BACKEND_RPMSG_WQ_STACK_SIZE=2048

```

Good idea on the basic test build - I will put something together - thanks!

[Susheel Nuguru]

ajlennon said:

Good idea on the basic test build - I will put something together - thanks!

Yes, that would be a good way to narrow down the problem.

[ajlennon]

OK I have simplified everything down and there is a test case here - see README for details

github.com/.../mps_test

[ajlennon]

I can make this lock up every time by running `ot ping 8.8.8.8` (or similar)

[ajlennon]

A bit more information... the MTD code that fails pinging on the nRF52840 dongle works OK on the nRF52833 DK (!?!)

[Shreya Patel]

I tried to flash the MTD code on nRF52833 DK and it is able to lock up the CLI after some time (for my OpenThread Network it takes 15 minutes).
Next, in debug mode, after it locks up (by doing ping 8.8.8.8), I get the below logs every time I try to continue debugging.