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