SOFTDEVICE ASSERTION 0x0002715e

[Simon]

Hello,

Looking for some background info for SOFTDEVICE ASSERTION 0x0002715e.
sdk 15.3, SD s132_nrf52_6.1.1

Maybe related,
there is no Assert if fds_record_write() is done before connecting,
but Assert received during fds_record_write() after connecting and CTS received (current time service).

thank-you,

[Simon]

I had been testing fds_init() to see if that was the issue.
The base CTS example does not have fds_evt_handler(),
but because CTS has to bond, FDS is being used used successfully.
When fds_evt_handler() is added, FDS_EVT_INIT returns FDS_SUCCESS,
and FDS_EVT_WRITE also returns FDS_SUCCESS.

If you comment current_time_print(p_evt), line 814,
and uncomment line 817, fds_write_1(),
then after connecting, and CTS is read,
each subsequent press of button 1 on the DK,
will successfully write the record by FDS.

At the top of the debug log, visible when opening the ticket,
you'll see the lines,
00> rec_id sample1 sample2 sample3 sample4
00> C  1  2  3  4
which indicates that the FDS has been properly initialized,
and record written by FDS.

I had also added a delay after the callback(),
and tried to initialize FDS once again after callback(),
all with the same unsuccessful result.

It still seems like that the nrf_cal_set_callback() function is
causing fds_record_write() to halt FDS.

thank-you,

[Simon]

and in DEBUG, this is what the HardFault_Handler() is showing:

[Simon]

repeated fds write using sdk 17.0.2, and same hardfault, pc(r15)=0x0002635e.

[Amanda Hsieh]

Hi Simon, 

The hardfault is caused by the sd_flash_write() which you cannot use the SD APIs from int. priority 3. Try to set it to '6' as

#define CAL_RTC_IRQ_Priority  6

-Amanda H.

[Simon]

Hi Amanda,

That setting worked, much appreciated.
Now the calendar cycles after fds write().
Not sure what led to that conclusion.
I had read this (only) other ticket in devzone,
but missed that last sentence.

thank-you,