This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_FAULT_ID_SD_ASSERT thrown from PC 0xBBDC

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_ASSERTPC = 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

  • 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?

  • 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.

  • 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.

  • 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

  • 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.

Related