Assertion failed in softdevice, pc=0x15520

[artgiroux]

Hi,

I'm trying to debug my application using monitor mode debugging and after setting a breakpoint while the code is running I usually have an assertion that fails in the softdevice and is handled by the app_error_fault_handler.

the handler is called with the following arguments:

* id = 1

* program counter =  0x15520

* info = 0

Could you give me some pointers on which assertion is failing in the softdevice?

Thanks.

[tesc]

Hi,

I cannot pinpoint the exact assert reason without knowing what SoftDevice (including version number) you got this on, but often it is the same kind of assert reason as when not using MMD.

Monitor Mode Debugging works by entering a loop at a given interrupt priority, so that higher priority interrupts (lower priority number) will continue running while lower priority interrupts (higher or equal priority number) are halted. If the priority for the debug monitor (the loop) is too high, it may still interfere with SoftDevice processing, to a degree where the SoftDevice asserts.

The priority can be set with a call at the top of main() to NVIC_SetPriority(DebugMonitor_IRQn, 6UL); for priority level 6, which is the highest priority not used by the SoftDevice on the nRF52 series. It allows for debugging code in main (thread) context, as well as application priority levels 7 and 6 (APP_IRQ_PRIORITY_LOW, where event handling happens), but not application priorities 3 and 2 which are higher than SVC / SD non-time-critical processing.

Regards,
Terje

[artgiroux]

Hi,

thanks for your reply.

We are using the NRF52 SDK 15.3, with the softdevice s140_6.1.1

The NVIC_SetPriority is already set to 6.

Best.

[tesc]

Hi,

That assert usually indicates that the SoftDevice has been blocked from timing-critical operation at priority 0.

In what context did you put the breakpoint, and what SoftDevice API calls and events have been going on leading up to the point of asserting?

Is there any timeslot API usage?

Can you share code and/or full project, either here in this public thread or in a new private ticket (refer to to this thread)? If you provide a (preferably minimal) example running on an nRF52840 DK we should hopefully be able to reproduce.

Regards,
Terje

[artgiroux]

I'm still investigating so I will try to give you more information and maybe some code to reproduce the problem but so far what I found is that if I put a breakpoint anywhere in the code after ble_advertising_start has been called then I will have this assert failure.

[tesc]

Hi,

That makes it sound like the priority has not been correctly set (or somehow reset), and/or that MMD is not fully functional. Can you provide a link to the guide / firmware / tutorial or other that you were following for setting up MMD? Alternatively describe the setup sufficiently for reproducing?

Maybe a long shot, but is there any chance that interrupts has been disabled when hitting the breakpoint, e.g. inside of a critical section?

Regards,
Terje