SOFTDEVICE ASSERTION 0x0002715e

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Tue, 01 Dec 2020 02:22:19 GMT

having,
#define HARDFAULT_HANDLER_ENABLED 1

shows,
<00> error> hardfault: HARD FAULT at 0x0002930E
<00> error> hardfault: R0: 0x0007E090 R1: 0x2000307C R2: 0x00000001 R3: 0x20003114
<00> error> hardfault: R12: 0x00000000 LR: 0x00029461 PSR: 0x61000034

which 0x0002930E leads to SD_FLASH_WRITE svc #029 as in this ticket,

then this ticket comment "interrupt handler running at priority 3, shouldn't call any Softdevice API .... can't run at that context level."
leads to CAL_RTC_IRQ_Priority=6
Seems like only this ticket links the pieces together.

thank-you,

RE: SOFTDEVICE ASSERTION 0x0002715e

Amanda Hsieh — Mon, 30 Nov 2020 07:55:43 GMT

Hi Simon,

If you add hardfault_handler_gcc.c (under nRF5_SDK\external\components\libraries\hardfault\nrf52\handler) to your project, it will show the hard fault at 0x0029032 which is SD_FLASH_WRITE. Most of that might be caused by initial or SD APIs priority.

-Amanda H.

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Fri, 27 Nov 2020 19:12:38 GMT

Not sure what the linkage is between the address of the hardfault at 0x0029032,
and CAL_RTC_IRQ_Priority=6?
Is this something that you just knew,
or there is some documentation as to the remedy?

When the requester verifies an answer,
the follow-up goes unanswered because the ticket is now Closed.

thank-you,

RE: SOFTDEVICE ASSERTION 0x0002715e

Amanda Hsieh — Fri, 27 Nov 2020 08:11:53 GMT

Hi Simon,

If you add hardfault_handler_gcc.c to your project, you might get the address of the hardfault as 0x0029032 which is sd_flash_write() called from nrf_cal_set_callback.

Please verify the answer to benefit other users seeking the solution if it helps.

-Amanda H.

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Thu, 26 Nov 2020 17:19:54 GMT

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,

RE: SOFTDEVICE ASSERTION 0x0002715e

Amanda Hsieh — Thu, 26 Nov 2020 13:18:44 GMT

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.

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Tue, 24 Nov 2020 23:37:46 GMT

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

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Tue, 24 Nov 2020 17:57:29 GMT

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

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Tue, 24 Nov 2020 17:28:10 GMT

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,

RE: SOFTDEVICE ASSERTION 0x0002715e

Amanda Hsieh — Tue, 24 Nov 2020 10:55:53 GMT

Hi Simon,

It seems you forgot to initial the fds in the uploaded project. Please see nRF5 SDK v15.3.0: Usage and Flash Data Storage Example on how to initiate the FDS.

-Amanda H.

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Mon, 23 Nov 2020 15:21:16 GMT

also, if fds_record_write() is commented, the calendar cycles properly as intended.

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Fri, 20 Nov 2020 05:57:31 GMT

I had been using WRITE_SIZE 1024 from another suggestion on devzone, but still the same issue.
The other bit of code merged was the Calendar example,
and it seems the function nrf_cal_set_callback() is what seems to be causing the Assert.
Without the callback(), the fds_record_write() is working ok.
I checked the suggestion by Torbjørn (ovrebekk), to make sure RTC2 is being used, and it is.

I merged sdk 15.3 CTS with Calendar and added the FDS write() to test on DK832 and reproduce the issue.
The fault happens in fds_write_1() during fds_record_write(), line 248 on SES.
(After connecting on nRF Connect, press button 1 on the DK).

thank-you,

devzone.nordicsemi.com/.../ble_5F00_app_5F00_cts_5F00_c_5F00_calendar_2D00_1_5F00_debug_5F00_log_2D00_1.txt

devzone.nordicsemi.com/.../3107.main.c

devzone.nordicsemi.com/.../ble_5F00_app_5F00_cts_5F00_c_5F00_calendar_2D00_1.zip

RE: SOFTDEVICE ASSERTION 0x0002715e

Amanda Hsieh — Thu, 19 Nov 2020 07:17:09 GMT

Hi Simon,

Sorry for the delay.

Could you try with a lower NRF_FSTORAGE_SD_MAX_WRITE_SIZE setting, 1024 for instance?

Is it possible to provide the debug log?

-Amanda H.

RE: SOFTDEVICE ASSERTION 0x0002715e

Simon — Thu, 19 Nov 2020 01:32:45 GMT

Update: tested with executing fds_record_write() just after connecting without CTS, and no Assert.
Tested with plain sdk CTS with DK832 and no Assert just after connecting, and no Assert after receiving CTS.
NUS was also merged, maybe missed something there, re-testing NUS with CTS.

thank-you,