NRF_FAULT_ID_SD_ASSERT thrown from PC 0xBBDC

[Elkana]

Hi,

I am using nRF52840, SDK 15.0, softdevice 6.0.0 (toolchain IAR 7 on windows).

My application runs on FreeRTOS 9.0.0 tickless (NRF_SDH_DISPATCH_MODEL 2).

I have a specific scenariothat throws error of type 0x0001=NRF_FAULT_ID_SD_ASSERT, PC = 0xBBDC and info = NULL.
The scenario doesn't include any BLE usage.

Do you have any clue on what could go wrong?

Is there a way to debug those SD asserts?

Thanks,

Elkana

[Susheel Nuguru]

The PC address is something new to me, so most likely this is something new you are seeing. 

can you help me reproduce this issue by attaching a minimalistic project to reproduce this?

[Elkana]

Not in the near future (stripping it may take a few days and I can't afford it right now).
I can tell you that it happens when the device is initially reset on external power + batteries, than when power is removed the assert occurs.
It is probably related to the way the module is initialized, because when initial reset is on batteries only - it is not reproduced even if you turn off and on the external power many times.

[Susheel Nuguru]

I can see that the only way the softdevice function at 0XBBDC asserts is if you have given an invalid clock_source to sd_softdevice_enable and ignored the failure return this function gives 0x1000.

Can you show me the snippet of your softdevice enable function with the possibility for me to evaluate its parameters.

[Elkana]

Hi,

We only call sd_softdevice_enable through nrf_sdh_enable_request on init - (without any changes from the original provided in the SDK):

ret_code_t nrf_sdh_enable_request(void)
{
    ret_code_t ret_code;

    if (m_nrf_sdh_enabled)
    {
        return NRF_ERROR_INVALID_STATE;
    }

    m_nrf_sdh_continue = true;

    // Notify observers about SoftDevice enable request.
    if (sdh_request_observer_notify(NRF_SDH_EVT_ENABLE_REQUEST) == NRF_ERROR_BUSY)
    {
        // Enable process was stopped.
        return NRF_SUCCESS;
    }

    // Notify observers about starting SoftDevice enable process.
    sdh_state_observer_notify(NRF_SDH_EVT_STATE_ENABLE_PREPARE);

    nrf_clock_lf_cfg_t const clock_lf_cfg =
    {
        .source       = NRF_SDH_CLOCK_LF_SRC,
        .rc_ctiv      = NRF_SDH_CLOCK_LF_RC_CTIV,
        .rc_temp_ctiv = NRF_SDH_CLOCK_LF_RC_TEMP_CTIV,
        .accuracy     = NRF_SDH_CLOCK_LF_ACCURACY
    };

    CRITICAL_REGION_ENTER();
#ifdef ANT_LICENSE_KEY
    ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler, ANT_LICENSE_KEY);
#else
    ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);
#endif
    m_nrf_sdh_enabled = (ret_code == NRF_SUCCESS);
    CRITICAL_REGION_EXIT();

    if (ret_code != NRF_SUCCESS)
    {
        return ret_code;
    }

    m_nrf_sdh_continue  = false;
    m_nrf_sdh_suspended = false;

#ifndef S140
    // Set the interrupt priority after enabling the SoftDevice, since
    // sd_softdevice_enable() sets the SoftDevice interrupt priority.
    swi_interrupt_priority_workaround();
#endif

    // Enable event interrupt.
    // Interrupt priority has already been set by the stack.
    softdevices_evt_irq_enable();

    // Notify observers about a finished SoftDevice enable process.
    sdh_state_observer_notify(NRF_SDH_EVT_STATE_ENABLED);

    return NRF_SUCCESS;
}

According to the debugger:

  clock_lf_cfg.source = 1

  clock_lf_cfg.rc_ctiv = 0

  clock_lf_cfg.rc_temp_ctiv = 0

  clock_lf_cfg.accuracy = 7

We did overload app_error_fault_handler (otherwise I wouldn't be able to give you the PC where it failed).

If this is related to LF Clock configuration - could it be that temporary glitch in the oscillator (due to electrical behavior when power source switches) cause this SD_ASSERT ?

Thanks,

Elkana

[Susheel Nuguru]

Elkana said:

If this is related to LF Clock configuration - could it be that temporary glitch in the oscillator (due to electrical behavior when power source switches) cause this SD_ASSERT ?

That is possible, Try to change the LF clock source to something else (like internal RC) and see if you still see it.

[Elkana]

MCU clock configuration is not a light thing to change.

sd_softdevice_enable fails with NRF_SDH_CLOCK_LF_SRC = 0, so I can't even start testing it 

[Susheel Nuguru]

I am out of theories then, I need to test this on my side to be able to reproduce and step into the softdevice code. We can change this to private case if you want. Please talk to your RSM if you worry about NDA 

[Elkana]

As I am working on a custom board (the image will fail very fast on Evalution Board)- I don't see how this can be done.