• 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).

  • 0 in reply to Susheel Nuguru

    Thanks for responding Susheel. So to try to show you what's happening a little more easily I've created two videos.

    The first shows a forked version of the CLI working in multiprotocol mode on the nRF5340

    https://youtu.be/OYG-1Hd4U_c

    The second is the same CLI code built for the nRF52840 dongle. You'll see it locks up fairly immediately. About 1:30-2 minutes in you can see it gets further then locks up.

    https://youtu.be/eps8GdLtuc8

    Hopefully this gives an indication of what I am seeing.

    Yes I was thinking the same in terms of the dual core versus single core maybe leading to some kinds of overflow.

    I've tried a few changes to increase stack sizes but to no avail.

    Any sign-posting on what I could attempt would be much appreciated!

  • 0 in reply to ajlennon
    1. What you do mean by "locking up"?

      Hopefully the above shows this. CLI stops responding

    2. Do you have a call stack trace in "locking up" state?

      Unfortunately not.

    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?

      Unfortunately not on the dongle
  • 0 in reply to ajlennon

    Without the debug info, there is little information for me to debug, but I will ask the experts to help me in this. Will be back to you when I find some guidance.

Reply Children
Related