SDC Assertion 13, 451

[Hayden Ball]

Hello.

Are you able to give any specific details around an SDC Assertion with File ID 13 and Line 451 please?

The nRF Connect version is v3.2.4.

I'm trying to isolate if this was likely to be a timing fault, but tracing so far has suggested this isn't likely to be a problem.

[Simonr]

Hi again

We are currently looking into this, but here's a progress update. We think the host on your side calls "sync terminate" right after the controller lost synchronization, but before the host was able to pull the sync lost event. We're currently trying to reproduce that to see why that is, as whenever the sync lost event is triggered the sync context should be cleaned up.

I'll let you know when I have more information.

Best regards,

Simon

[Simonr]

Another update today. We have now reproduced the issue on our end, and are looking into workarounds. You can terminate the sync from the sync side or accepting the assert and resetting, but we are working to find a proper solution/fix to this issue as well.

Best regards,

Simon

[Hayden Ball]

Thank you Simonr .

I'm not fully following - what do you mean by "terminate the sync from the sync side"?

For our application, we wouldn't be able to terminate from the advertiser side, if that's what you mean?

If we were to "squash" the assertion by overriding `bt_ctlr_assert_handle` to not reset, would this be safeish to do, or is this likely to lead to undefined behaviour?