Deciphering bt controller assert

[asrm]

I'm getting this in my bt controller assert handler:

48 is the file and 260 is the line that our handler is getting.  This is on ncs 3.2.4

[Simonr]

Hi Andy

To avoid confusion, please share the assert message formatted as you see it in your logs, and what Bluetooth Controller are you using, the SoftDevice controller or Zephyr BT controller? Also, please share some details on what your BT controller application is doing, when this error message occurs, and the prj.conf file of your application so we can see what configurations are enabled.

Best regards,

Simon

[asrm]

We're using the soft device.  These logs were in a device we puled from the field so I don't know what it was doing at the time.

This was the log in our custom ble handler.

BT_CTLR ASSERT: 48, 260

void bt_ctlr_assert_handle(char* file, uint32_t line)

{

snprintk(

m_assert_record.buf, sizeof(m_assert_record.buf),

"BT_CTLR ASSERT: %s, %u\n", (char*)file, line

);

Our config is fairly deep are there particular items you're looking for?

[Simonr]

Hi

Are you working on the nRF52840 here? This assert seems to point to the radio event manager callback not having the correct signal reported. It's hard to point to what could cause this, so I suggest you share some details on what your controller is doing exactly. Any configs on what Bluetooth controller features are used would be helpful. Also please confirm you're using the nRF52840 as is tagged on this ticket.

If you'd like we can set this ticket to Private mode in order to keep any code snippets or configs you share private between you and Nordic employees. Let me know if that's the case and I'll get on that.

Best regards,

Simon

[asrm]

I believe we have this tracked to an accidental arming of timer0 when we didn't have an active radio timeslot.  Would that have caused this assert?

we also sometimes see the assert 48, 218.  seemingly from the same timer arm.  Does that assert also line up with a timer armed when we don't have the radio?

[Simonr]

Yes, this is also a radio event manager callback not having the correct signal reported. 

Timer0 should be used exclusively by MPSL and the SoftDevice controller, so if you manually arm this then it sounds very likely that this is the cause of this assert. Have you seen that the assert stops occurring if you make sure the timer0 is not accidentally triggered.

Best regards,

Simon