sd_softdevice_is_enabled somtimes hardfaults

[Christer Fletcher]

During some operations like factory reset, or during a hardfault we want to check if the softdevice is enabled and disable it if it is enabled before continuing with further operations. For example during factory reset, or forget device and we want to erase the flash are with the bonding information.

However, sometimes sd_softdevice_is_enabled hardfaults.

We are using s140 and SDK v15

Here are registers at the time of crash:

(gdb) info reg
r0             0x200298d7          537041111
r1             0xa8e35             691765
r2             0x10000000          268435456
r3             0x1000              4096
r4             0xf5                245
r5             0x3                 3
r6             0x200281f4          537035252
r7             0x200281ec          537035244
r8             0x0                 0
r9             0x4a646e            4875374
r10            0x4a646f            4875375
r11            0xa5a5a5a5          -1515870811
r12            0xfa000000          -100663296
sp             0x200298d0          0x200298d0 <task_TIME+1568>
lr             0x59635             366133
pc             0x595fe             0x595fe <sd_softdevice_is_enabled+2>
xpsr           0x81000000          -2130706432
msp            0x20037fe0          537100256
psp            0x200298b0          537041072

[Vidar Berg]

Hello,

Could you please post a stack trace ( (gdb) bt full) when the program has entered the fault handler? SoftDevice APIs are implemented with Suerpvisor Calls and cannot be called from an interrupt context that has higher priority than the supervisor call itself. Therefore, it cannot be used within the hardfault exception handler. Doing so will lead to another fault. Instead you can disable the SD sandboxing as explained in this post:  Disable Softdevice sandboxing in fault handler .  

Here are registers at the time of crash:

I don't see any reasons for why it would crash here. The program is not running in an interrupt.

Best regards,

Vidar

[Christer Fletcher]

(gdb) bt full
#0  0x000595fe in sd_softdevice_is_enabled (
    p_softdevice_enabled=p_softdevice_enabled@entry=0x200298d7 <task_TIME+1575> " ")
    at SDK/v15/components/softdevice/s140/headers/nrf_sdm.h:337
No locals.
#1  0x00059634 in fstorage_erase () at app/fstorage/fstorage.c:47
        fstorage_page_start = 245
        fstorage_page_end = <optimized out>
        sd_enabled = 32 ' '
#2  0x00031a46 in runlevel_shutdown_factory_reset () at app/runlevel.c:539
        r = <optimized out>
#3  0x0009a3ba in prvProcessExpiredTimer (xTimeNow=4875375, xNextExpireTime=4875374)
    at external/FreeRTOS_Kernel/timers.c:500
        xResult = <optimized out>
        pxTimer = 0x20032cd4 <timer_FactoryR>
#4  prvProcessTimerOrBlockTask (xListWasEmpty=<optimized out>, xNextExpireTime=4875374)
    at external/FreeRTOS_Kernel/timers.c:560
        xTimeNow = 4875375
        xTimerListsWereSwitched = 0
        xTimeNow = <optimized out>
        xTimerListsWereSwitched = <optimized out>
#5  prvTimerTask (pvParameters=<optimized out>) at external/FreeRTOS_Kernel/timers.c:533
        xNextExpireTime = 4875374
        xListWasEmpty = <optimized out>
#6  0x0009a5ec in xTimerPendFunctionCall (xFunctionToPend=<optimized out>,
    pvParameter1=<optimized out>, ulParameter2=<optimized out>, xTicksToWait=<optimized out>)
    at external/FreeRTOS_Kernel/timers.c:1051
        xMessage = {
          xMessageID = -1515870811,
          u = {
            xTimerParameters = {
              xMessageValue = 2779096485,
              pxTimer = 0xa5a5a5a5
            },
            xCallbackParameters = {
              pxCallbackFunction = 0xa5a5a5a5,
              pvParameter1 = 0xa5a5a5a5,
              ulParameter2 = 632301
            }
          }
        }
        xReturn = 537041111
#7  0x2002993c in task_TIME ()

[Vidar Berg]

The stack trace does not show the fault handler.

[Christer Fletcher]

True, that's how our fault handler is setup. It saves the registers at the time of the faults and makes our crash dump look this way. I'm uncertain if I can get  you the locals from the fault handler. Is it something special you are looking for? I might have it somewhere in my dump file.

[Vidar Berg]

So the backtrace is from a saved coredump, or is GDB connected to your target device when you experience the crash? What I'm really looking for is the fault exception type. This information will be printed to the debug terminal if you use our hardfault handler (https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/lib_hardfault.html) 

Edit: I noticed this from frame #6, which looks a bit suspicious.

            xCallbackParameters = {
              pxCallbackFunction = 0xa5a5a5a5,
              pvParameter1 = 0xa5a5a5a5,
              ulParameter2 = 632301

Have you tried increasing your stack sizes?

[Christer Fletcher]

Yes, this is a saved coredump. The crash happens very infrequently and so far we have been able to re-produce it with gdb attached to target.

0xa5a5a5a5 is what we fill all our stacks with when booting. There's currently 143 words of that on the top of the stack of the TIME task that . So there's plenty of free stack in the TIME task.

I seem to have 76 words free in the "main" task where I believe interrupts are executed.

Or is it a different stack size I should check?