• State Not Answered
  • Replies 17 replies
  • Subscribers 90 subscribers
  • Views 3107 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 313182
Options

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

Parents
  • 0

    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?

    It seems like a stack overflow issue, but to be able to confirm this and debug I would have to know more details from you.

    1. What you do mean by "locking up"?
    2. Do you have a call stack trace in "locking up" state?
    3. Can you start a app in debugger and reproduce the issue and get the context of the code that is being executed in this locked up state?

    The CPU on nRF52 is slower than nRF53 (nRF53 also is dual core which makes it even more efficient in pre and post processing of radio packets). 
    So a single core on nRF52 might not be just enough to process both of your OpenThread and BLE activity and is causing the buffers to overflow (my guess).

Reply
  • 0

    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?

    It seems like a stack overflow issue, but to be able to confirm this and debug I would have to know more details from you.

    1. What you do mean by "locking up"?
    2. Do you have a call stack trace in "locking up" state?
    3. Can you start a app in debugger and reproduce the issue and get the context of the code that is being executed in this locked up state?

    The CPU on nRF52 is slower than nRF53 (nRF53 also is dual core which makes it even more efficient in pre and post processing of radio packets). 
    So a single core on nRF52 might not be just enough to process both of your OpenThread and BLE activity and is causing the buffers to overflow (my guess).

Children
Related