• State Verified Answer
  • Replies 7 replies
  • Subscribers 74 subscribers
  • Views 1464 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 299717
Options

Zephyr observer app with CONFIG_BT_EXT_ADV=y triggers bt_ctlr_assert_handle

Joerg Wunsch

On a 52840 USB stick, I successfully tested the "observer" demo app.

Now, I tried to extend it by enabling CONFIG_BT_EXT_ADV=y which is supposed to print some details about received advertisements.

This triggers an "assertion failed". I installed bt_ctlr_assert_handle, and it says "file 53, line 826". OK, at least it's not "file 42" :-), but nevertheless I'm at a loss what the assertion wants to tell me. It apparently triggers inside the nRF library code, in a function with an obfuscated name (sym_476LRB5XNUARAHCHHC7ZAIGPFC5VZ4W2N4467LI), with the Bluetooth Rx thread.

Can anyone enlighten me what's the cause of this failed assertion?

  • 0 in reply to Einar Thorsrud

    The file name / line numbers are exactly that (as mentioned in my first message), file "53", line 826.

    OK, timing issue might explain it a bit, parsing the message probably takes some time. I could rearrange the code to only record the message details in the callback, and then parse it later. Probably a good idea anyway.

    Sorry, yes, I mistyped the assert handler in the first message: of course, an MPSL assert (I had a BT CTRL assert once as well, so I installed both handlers).

  • 0 in reply to Joerg Wunsch

    *** Booting Zephyr OS build v3.2.99-ncs1-rc1 ***
    Starting Observer Demo
    Registered scan callbacks
    Started scanning...
    Device found: 03:02:68:F7:A6:79 (random) (RSSI -72), type 3, AD data len 15
    [DEVICE]: 01:04:89:20:00:52 (0x40), AD evt type 0, Tx Pwr: 1, RSSI -84 Data status: 0, AD data len: 15 Name: C:1 S:0 D:0 SR:0 E:0 Pri PHY: Unknown, Sec PHY: Unknown, Interval: 0x0000 (0 ms), SID: 183
    Device found: 03:02:68:F7:A6:79 (random) (RSSI -72), type 3, AD data len 15
    [DEVICE]: 01:04:89:20:00:52 (0x40), AD evt type 0, Tx Pwr: 1, RSSI -84 Data status: 0, AD data len: 15 Name: C:1 S:0 D:0 SR:0 E:0 Pri PHY: Unknown, Sec PHY: Unknown, Interval: 0x0000 (0 ms), SID: 183

    Rearranged the code. scan_recv() now just records both pointers, and there's a separate scan_print() (called from the main thread) that arranges for the printout of recorded data. That works as expected.

    Thanks for pointing out that the assertion is a timing issue, that was the key to solve it.

Related
Terms of service