S140: Assertion at address 0x12CFA when connecting to device

[denwil]

Hi,

I'm having problems connecting to my device, because whenever I do so, the SoftDevice asserts at address 0x12CFA.

I use softdevice S140 v6.0.0 and SDK v15.0.0.

I initalize the system like it is done in examples/ble_peripheral/ble_app_hrs_freertos but only initialize the DIS service, and I don't use peer manager.

The device initializes correctly and starts advertising. In the NRF Connect App (Android), I can connect but when the "Discovering Services" text shows, I see that my device has crashed on

the SoftDevice assert on 0x12cfa. Can you please help me debug this issue?

Best regards,

Dennis

[denwil]

Found the solution to this. Had to add this to nrf_sdh_freertos.c:

#include "nrf_soc.h"

This is needed for the linker to correctly override the default handler with SD_EVT_IRQHandler, since the nrf_soc.h defines SD_EVT_IRQHandler to SWI2_IRQHandler (or on nrf52840, SWI2_EGU2_IRQHandler). I do not know how it could have worked without that include.

So the SoftDevice assert I was seeing was probably due to the debugger halting the processor, and then when stepping, the SoftDevice detected that timing was off and asserted. But it would be nice with some info on how to detect what errors the SoftDevice can assert on.

Best regards,

Dennis

[Elkana]

The nrf_soc.h include is not required if SOFTDEVICE_PRESENT is defined, since it is already included: "FreeRTOS.h" -> "FreeRTOSConfig.h" -> "nrf_soc.h"

You can check preprocessor output and validate it replaces SD_EVT_IRQHandler with SWI2_EGU2_IRQHandler (so this is why it works).

I have the same issue (SD assert with PC = 0x12cfa) on nRF52840, and I don't understand how the SWI2 interrupt related to the Assertion, and how do you tell? 

[denwil]

Elkana said:

"FreeRTOS.h" -> "FreeRTOSConfig.h" -> "nrf_soc.h"

Ok, that works but not a very nice implicit include.

Elkana said:

I have the same issue (SD assert with PC = 0x12cfa) on nRF52840, and I don't understand how the SWI2 interrupt related to the Assertion, and how do you tell?

It didn't directly relate to the interrupt issue, but was rather a side effect of debugging while the bluetooth stack is running. If the bluetooth stack notices that it is out of sync (e.g. when you are stepping through code with the debugger) it will assert there.

[Elkana]

I also noticed that this is related to Stack out of sync, and this is very disappointing:
1.  In my opinion, Faults in BLE stack should not automatically reset the device, but shutdown the BLE back to idle and tell the user about it.
2. Since this is probably a very common error - The error could have been much more descriptive, and save loads of debugging hours...

[denwil]

Could not agree more...