SOFTDEVICE: ASSERTION FAILED while running mesh.

[bart]

Hi, I'm getting regular crashes with my app: SOFTDEVICE: ASSERTION FAILED.

Using and NRF52832, SDK 15.3.0, SD 132 6.1.1, and Mesh SDK 3.1.0.

With DEBUG defined, I don't really get more info: id=1, pc=148742, info=0.

The last mesh log usually is something with TX (mostly net_beacon.c,  265, BEACON TX).
One crash, I also had a log of getting event NRF_EVT_RADIO_SESSION_IDLE.

I use the mesh SDK to communicate via mesh between nodes, to advertise iBeacon (100ms interval), and I use the scan callback. Next to that, I also use the SD to advertise service data.

Parameters:

	nrf_clock_lf_cfg_t lfclksrc;
	lfclksrc.source = NRF_SDH_CLOCK_LF_SRC;
	lfclksrc.rc_ctiv = NRF_SDH_CLOCK_LF_RC_CTIV;
	lfclksrc.rc_temp_ctiv = NRF_SDH_CLOCK_LF_RC_TEMP_CTIV;
	lfclksrc.accuracy = NRF_CLOCK_LF_ACCURACY_20_PPM;

	mesh_stack_init_params_t init_params;
	init_params.core.irq_priority       = NRF_MESH_IRQ_PRIORITY_THREAD;
	init_params.core.lfclksrc           = lfclksrc;
	init_params.core.p_uuid             = NULL;
	init_params.core.relay_cb           = NULL;

Any idea of what causes this crash?

[Bjørn Kvaale]

Let me see if I can get a hold of a softdevice elf file. Then we could use the addr2line tool to see where the softdevice assert is occuring. I will get back to you soon.

[Bjørn Kvaale]

What happens if you decrease the iBeacon advertising interval to say every 2 seconds? Do you get the assert then?

[Bjørn Kvaale]

Which priorities are you running in your example (see link)?

[bart]

All mesh functions are called from thread, from the main loop (I'm using the app scheduler).

Edit: while checking your link, I do notice that I hadn't set NRF_SDH_DISPATCH_MODEL to 1 yet. I will try and see if that helps. Until now, I manually put events that I actually use on the app scheduler. Does this setting matter for the mesh code?

Edit2: With NRF_SDH_DISPATCH_MODEL 1, I'm still getting the crash.

The one that's easiest to reproduce is the one on boot, where i get timeouts from FDS, and then this event 7 (NRF_EVT_RADIO_SESSION_IDLE).

The back trace I have in that case:

#0  0x0003b012 in app_error_fault_handler (id=1, pc=86552, info=0) at (...)/SDK-15-3/components/libraries/util/app_error_weak.c:100
#1  0x00023de8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) info registers
r0             0x0    0
r1             0x1    1
r2             0xe000e100    3758153984
r3             0x80000000    2147483648
r4             0x10001    65537
r5             0x0    0
r6             0x1    1
r7             0x15218    86552
r8             0x0    0
r9             0x20005eac    536895148
r10            0x20000000    536870912
r11            0x0    0
r12            0x0    0
sp             0x2000fd98    0x2000fd98
lr             0x3c0b9    245945
pc             0x3b012    0x3b012 <app_error_fault_handler+110>
xpsr           0x810f0003    2165243907
msp            0x2000fd98    536935832
psp            0x0    0
primask        0x1    1
basepri        0x0    0
faultmask      0x0    0
control        0x0    0
fpscr          0x80000010    2147483664

[bart]

Also tried with PERSISTENT_STORAGE 0, but still getting the same crash.

[bart]

I tried setting TIMESLOT_END_SAFETY_MARGIN_US to 1000. In that case, I still quite often get the FDS timeouts on boot, but it doesn't result in the event NRF_EVT_RADIO_SESSION_IDLE, and a softdevice assert anymore.

Does that mean the 100 is too tight? How do you determine the correct value?

[Bjørn Kvaale]

Have you tried using the addr2line tool? How are you doing the iBeacon advertising? Could you upload some code so we can double check how you are doing this? Are you using the softdevice to do the iBeacon advertising?

[bart]

I tried, but only get ??:0 Don't you need the softdevice elf for that address?

Here you can see the code, but as i said, i had the crashes even without the mesh doing the advertising. The softdevice is also advertising a different payload.

So far, i didn't get a crash yet with the margin set to 1000, while both mesh and softdevice are advertising.

[Bjørn Kvaale]

Very sorry for the delayed response. As you can see from this blog post, you use the Timeslot API directly to communicate between the Mesh stack & the softdevice. The softdevice is only used for the iBeacon advertising. From your code, it seems there is definitely something wrong with the timeslot of the iBeacon advertisement. 

Have you taken a look at one of the coexist examples between Mesh & BLE UART for example? I will take a closer look tomorrow morning.

[bart]

Hey Bjorn,

I'm aware of the mesh using the timeslot API. And I looked at the ble_app_proximity_coexist example, is the uart one more relevant?

Like I said before, even without the iBeacon advertising, I still got the crashes, so I fail to see how that can be the main cause. Did you maybe mean the advertising i do directly via the SD (which are not iBeacon advertisements)? The ibeacon advertising is done via the mesh api, not directly via the SD.

Also like I said before, ever since I set TIMESLOT_END_SAFETY_MARGIN_US to 1000, I don't get the crash anymore:

I tried setting TIMESLOT_END_SAFETY_MARGIN_US to 1000. In that case, I still quite often get the FDS timeouts on boot, but it doesn't result in the event NRF_EVT_RADIO_SESSION_IDLE, and a softdevice assert anymore.

Does that mean the 100 is too tight? How do you determine the correct value?

[Bjørn Kvaale]

So sorry for the delayed reponse again! I have asked internally & the quick answer is do not use FDS. FDS with Bluetooth Mesh will lead to timeslot issues & SD asserts. Much easier to use the provided flash manager in the mesh sdk. A lot easier to use too from what I have heard.

[Bjørn Kvaale]

Another update: "As I see, they are using FDS. If you see the mesh SDK documentation:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v3.2.0/md_doc_getting_started_how_to_nordicSDK.html?cp=5_2_1_7

We mention that:

nRF5 SDK NVM storage modules

Using nRF5 SDK modules such as fstorage, pstorage, or ble_flash for writing to flash may be problematic due to long timeslot events occupied by the mesh stack. Use the Flash manager module provided by the mesh stack instead.

He can either use flash manager or better, mesh_config, as used in various other internal modules.

Also, for beacon advertising, if possible, use the Mesh advertiser instead of SD advertiser."