assert_nrf_callback failed 1378@ll_lm.s0.c

[Karl]

Hi pros, Im recently working on 51822QFAAG2 with S110 v7.10 and SDK v6.10.

My app always triggers this assert after BLE is enabled and busy transferring for some time.

In my case, 51822 is working as a SPI-BLE bridge, which means it receives from BLE and forward to another chip via SPI, vice versa.

I searched all related questions about ll_lm.s0.c and got no clue for this. Any hint, please?

[Ulrich Myhre]

Hi Karl

There are actually multiple things that can trigger this assert, hence my first thought being the older chip revision. It can also be triggered if you disable interrupts globally (like with the mbed Ticker) at inopportune times, or if your clock source is less accurate than what you stated.

There was a similar question that hit this issue earlier: devzone.nordicsemi.com/.../

I would recommend you to take this to a support ticket if you are having troubles, as they might have a workaround for you. For now this is a known issue that might be fixed for later versions. The peripheral in the S120 2.0.0 and the S130 should not be affected by this.

[Karl]

Thanks you Ulrich.

I tried s110 v7.0.0 with SDK 6.1.0, the problem still exists, only the line number changes to #1396.

By the way, I checked the Compatibility Matrix and found out that the QFAAG2 is tagged with rev.2 and the lower table says rev.2 is compatible both with softdevice 710 and 700. Anything I missed?

[Ulrich Myhre]

You are right, I was looking at an outdated version of it. I will update my answer with more relevant information.

[Karl]

Thanks for the tip. I checked my code, there's no such op as disabling interrupts globally. And I consulted our hardware engineer, the clock source is accurate enough. Then I tried migrating to Softdevice 8.0.0 with SDK 8.1.0, which has been working pretty well, no stack-assert triggered yet.