SoftDevice with Zephyr : Scanning extended advertisement packets crash the application

[Paul from Nofence]

Context

We are working on a project that implies advertising and scanning extended advertised packets.

details :

• NRF52840
• Zephyr SDK 17.0
• Zephyr 4.0.99
• NRF SDK v3.0.0-preview1

Issue description

Our application freeze after a few seconds of scanning. The logs show that the bt hci driver generates a large number of BT_HCI_EVT_LE_EXT_ADVERTISING_REPORT (0x0d) events (the number of events before the crash is not constant) and then we get an error, either mpsl_init: MPSL ASSERT: 112, 1984, or bt_sdc_hci_driver: SoftDevice Controller ASSERT: 50. Both cases it leads to an OS Hard fault. We are working in an office with a lot of devices advertising, so we tried to put the device in a Faraday box and observed that the bug happens immediately when we open the box and not before.

Theory

We think this might be a configuration issue and we spent some time trying to play with different buffer sizes but no relevant results.

More contexts:

BLE related configuration :

# Bluetooth Configuration
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_CTLR=n
CONFIG_BT_EXT_ADV=y
CONFIG_BT_EXT_ADV_MAX_ADV_SET=2
CONFIG_BT_BROADCASTER=y
CONFIG_BT_CTLR=y
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_HCI=y
CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_CTLR_ADV_DATA_CHAIN=n
CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=1500
CONFIG_BT_OBSERVER=y

Scan enable function (return 0, and bt_enable(NULL) has returned 0 before that)

static int ble_scan_start()
{
    struct bt_le_scan_param scan_param = {
        .type = BT_HCI_LE_SCAN_PASSIVE,
        .options = BT_LE_SCAN_OPT_NONE,
        .interval = 37 / 0.625,
        .window = 25 / 0.625,
    };

    int err = bt_le_scan_start(&scan_param, scan_cb);
    return r;
}

 

Our scan cb is empty, proving that the issue do directly come from the application but from on of the lower layer.

Captured logs:

[Sigurd]

Hi!

I'm checking with our SoftDevice Controller team what the reason for these asserts could be.

[Paul from Nofence]

Hi, 
Thank you, but we may have found the solution : adding CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL=y in the prj.conf.

[erlendhestnes92]

Hi Sigurd,

Thanks for the feedback and sorry for the late reply from our side. We also want to understand this issue better as setting the CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL=y seems to be a bit of magical solution to this problem as we're afraid that something on our side is not correctly configured. I therefore now tried as you suggested:

1) Flashed the Bluetooth central example that you suggested an enabled CONFIG_BT_EXT_ADV=y together with BLE logging over RTT. This example works, in other words I don't see that we are crashing. And for reference, using our application with CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL=n makes our application crash in the same fashion as described above.

2) We are not using the radio directly, only through the Bluetooth API. Neither are we RTC0 for something (it's only set to okay in our DTS), nor are we knowingly interacting with clocks or disabling interrupts for long period of time.

3) We are not doing anything with the clocks

Do you have any more suggestions for us to try?

Best regards,
Erlend

[Sigurd]

Hi!

Could you post the compiled .overlay and .config files for your application?

[erlendhestnes92]

Thanks for getting back, here are the .config and .dts file of our application.

Best regards,
Erlend
_dts_and_config.zip

[joar@nofence]

Hi Sigurd (@sigurdon),

Just checking in—are there any updates on this?

Also, are the error codes from the closed-source SoftDevice documented anywhere?
Specifically, do we know where the SoftDevice Controller ASSERT: 50 originates from?

[Sigurd]

Hi!

We are not able to reproduce the issue.

erlendhestnes92 said:

Flashed the Bluetooth central example that you suggested an enabled CONFIG_BT_EXT_ADV=y together with BLE logging over RTT. This example works, in other words I don't see that we are crashing.

Since the scanner example works, then it indicates that there is something in your application which makes it behave differently than the simple scanning application, and triggers the issue.

Are you able to provide a stripped down example application which can reproduce the issue? Maybe this can be done by modifying the scanner sample ?

[joar@nofence]

I’ll give this a try tomorrow. In the meantime, if you’re able to share any additional documentation on SoftDevice error codes, it would be greatly appreciated. Thanks!

[Sigurd]

Hi!

erlendhestnes92 said:

here are the .config and .dts file of our application.

We had a look again at these files, and we see these configs:

CONFIG_COUNTER=y
CONFIG_COUNTER_NRF_RTC=y
CONFIG_COUNTER_RTC_CUSTOM_TOP_SUPPORT=y

Could you try setting these to n , and see if that impacts the issue ?

hypothesis: It could be that the IRQ handler for MPSL were overwritten by this counter driver: https://github.com/nrfconnect/sdk-zephyr/blob/eacfed3332af6f473c97b6888594ea9d74e0149f/drivers/counter/counter_nrfx_rtc.c#L696-L753

[joar@nofence]

Great, thank you! That seems to have resolved the issue. Setting CONFIG_COUNTER=n appears to prevent the SoftDevice from asserting in our application. And yes, in general, just enabling CONFIG_COUNTER=y in the Bluetooth Central sample causes the SoftDevice to assert.

It might be beneficial to include a build-time warning or error when this configuration combination is detected, to help avoid similar issues in the future.