SOFTDEVICE: ASSERTION FAILED pc: 0x00025B94

[AshLabs]

Hi all

So i had a working running example on SDK Thread and Zigbee V3.0.0.
This flavor used the softdevice s140_nrf52_6.1.1_softdevice.hex
I've migrated to the new SDK being nRF5_SDK_for_Thread_and_Zigbee_v4_1_0.
I now use the soft device s140_nrf52_7.0.1_softdevice.hex.

I have a custom PCB with 2 NRF52840 modules on them from Fanstel.
Both have a crystal oscillator circuit for the LFCLK. 
The 32KHz crystal has a 12pF capacitance, with 2 12pF load caps at the ends.

The application was running smoothly with the SDK V3.0.0.
The application is a BLE + OT combination. I also have the LIBUARTe running.
I've used the SDK variant with the USB Transport layer, so i have UART0 for debug logging and UART1 for the libUARTe for RS485.
I've migrated the SDK to V4.1.0, and was still flashing the old softdevice (eg. 6.1.1) to it.
When the application ran, i got SOFTDEVICE: ASSERTION FAILED crashes.

I then migrated to the new softdevice eg. V7.0.1.
The assertions still come up. I've added pc logging and the error_handler fails at PC 0x00025B94.
Looking at this forum i've found 2 NRF_RAAL_TIMESLOT_DEFAULT_SAFE_MARGIN_US bug entries with suggests increasing the margin on the LFCLK.

Changing the NRF_RAAL_TIMESLOT_DEFAULT_SAFE_MARGIN_US from 3 to 20 or 35 has no effect.

While logging i get this result:

<error> app: SOFTDEVICE: ASSERTION FAILED pc: 0x00025B94
<error> app: SOFTDEVICE: INVALID MEMORY ACCESS

My suspicion is that it has to do with the SDK, since both softdevices V6.1.1 and V7.0.1 have this behaviour.
I cannot look at the .MAP file for the soft device to see where it crashes.
Anyone has some pointers in going forward ?

[AshLabs]

Hey Hung,

The INVALID MEMORY ACCESS error can be ignored (i cannot edit my original post). This was printed since i accidentally removed the break in this switch case.

Im running the Bluetooth stack together with openthread.
So it's using the multiprotocol stack, 802.15.4 alongside BLE.

So it's not a memory access issue.
From the other issues regarding the same PC error address, i'd surely say it would be the hardfault handler.

Now the question is why the hardfault handler is called. Is it a WDT issue ?
I would think it would be an assert, but question is from which block..

I've tried correlating it with the advertisement updating i'm doing. But that does not seem to be correlated time-wise.
The timestams on the issue are not deterministic. I will give you some crash times since boot:
- 90 seconds
- 40 seconds
- at 120 seconds everything just froze up
- 73 seconds
- 32 seconds

The application has openthread communication, i2c communication running constantly, libuarte for rs485 communication running, NUS over BLE running.

[Hung Bui]

OK I see. I would suggest to try reduce the time you take to handle interrupt. The way the Thread and BLE work together is by using timeslot. I suspect that the could be some timeslot violation here causing the issue.

If you spend lots of time handling interrupt you may try to reduce that. 

You can temporarily remove some of the features in your application one by one to check if it is the cause of the crash. 
I don't think it's WDT. If the WDT triggers you will just have a reset. 

[AshLabs]

Ok update. I Disabled the Advertisement block -> No change.
I've disabled the Openthread functions -> 0x00025B94 PC error went away.
So it's coupled to the Openthread stack. I have the room to leave this disabled to meet my deadline, so i will investigate further.

I now use the NUS service to communicate between RS485 and a BLE device. While this flow works, i now sometimes get a softdevice assert with 0x15A80.
Back to searching for this issue.

[Hung Bui]

Hi Robbe, 

0x15A80 points to Radio Event Manager. It's an assert about timing of the radio. 

When you mentioned disable Openthread function, do you mean you disable completely the operation of Thread stack or you simply disable any activity in the application related to Thread ? 

I would suggest to try testing using our example in the SDK just so that you have a platform that can run both BLE and Thread, after that you can start adding your feature /custom service in. 

Again, make sure you configure the interrupt priority with correct level (App High/ App Low). 

[AshLabs]

Update:
This issue is related to the libUARTe.
It's necessary to set the interrupt priority for the nrf_libuarte_async_config_t.
eg. .int_prio = 2.

This is what was causing the 0x15A80 SD assert.
After some changes, my openthread otSysInit() function is giving me NRF_ERROR_INVALID_STATE.
So i hope after fixing this, that im fully up and running.

[Hung Bui]

HI Robbe, 
Please double check on what return NRF_ERROR_INVALID_STATE , as I can see in the code otSysInit() should not return any value it's a void return function. 
Please try to compare your application to our examples in the SDK to see if you can spot any difference that can cause the assert.