Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Ending up in error handler with sdh_stack_observer on the call stack

It seems like I should be able to find this in docs somewhere but having trouble finding the information.

What exactly is the sdh_stack_observer and if I'm ending up in an error handler with sdh_stack_observer shown on the debugger call stack and not much else, what should I be looking for or what is this an indication of?

Parents
  • Hi,

    A SoftDevice stack observer receives events from the SoftDevice. It is part of the the SoftDevice Handler library, and the library will forward stack events from the SoftDevice to the parts of application that have registered themselves as observers.

    Could you provide some more information about how the call stack looks like ?

    Maybe you could upload a screenshot?

    I recommend adding the preprocessor define "DEBUG" to your project in order to enable blocking assertions. It's also important that you set the optimization level to 0 when debugging to get the proper call graph.

  • Thanks - I've made sure DEBUG info is turned on. I'm getting a hard fault when calling nrf_sdh_enable_request. I don't see any issues with the arguments.  Could it be related to the low frequency clock already enabled before the soft device is getting enabled?  I do have another project that enables fine. I have not been able to figure out what the difference is.

    <error> hardfault: HARD FAULT at 0x000281AA
    <error> hardfault: R0: 0x200030C0 R1: 0x00028455 R2: 0x00000000 R3: 0x000313CB
    <error> hardfault: R12: 0x00000009 LR: 0x000280E3 PSR: 0x6100000B

Reply
  • Thanks - I've made sure DEBUG info is turned on. I'm getting a hard fault when calling nrf_sdh_enable_request. I don't see any issues with the arguments.  Could it be related to the low frequency clock already enabled before the soft device is getting enabled?  I do have another project that enables fine. I have not been able to figure out what the difference is.

    <error> hardfault: HARD FAULT at 0x000281AA
    <error> hardfault: R0: 0x200030C0 R1: 0x00028455 R2: 0x00000000 R3: 0x000313CB
    <error> hardfault: R12: 0x00000009 LR: 0x000280E3 PSR: 0x6100000B

Children
  • Hi,

    Do you have a low frequency crystal in your design ?

    Do you have the same issue if you use the LF RC oscillator? I.e. in sdk_config.h, use the following:

    // </h> 
    //==========================================================
    
    // <h> Clock - SoftDevice clock configuration
    
    //==========================================================
    // <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
     
    // <0=> NRF_CLOCK_LF_SRC_RC 
    // <1=> NRF_CLOCK_LF_SRC_XTAL 
    // <2=> NRF_CLOCK_LF_SRC_SYNTH 
    
    #ifndef NRF_SDH_CLOCK_LF_SRC
    #define NRF_SDH_CLOCK_LF_SRC 0
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
    #ifndef NRF_SDH_CLOCK_LF_RC_CTIV
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
    // <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
    // <i>  if the temperature has not changed.
    
    #ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_XTAL_ACCURACY  - External crystal clock accuracy used in the LL to compute timing windows.
     
    // <0=> NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM 
    // <1=> NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM 
    // <2=> NRF_CLOCK_LF_XTAL_ACCURACY_150_PPM 
    // <3=> NRF_CLOCK_LF_XTAL_ACCURACY_100_PPM 
    // <4=> NRF_CLOCK_LF_XTAL_ACCURACY_75_PPM 
    // <5=> NRF_CLOCK_LF_XTAL_ACCURACY_50_PPM 
    // <6=> NRF_CLOCK_LF_XTAL_ACCURACY_30_PPM 
    // <7=> NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM 
    
    #ifndef NRF_SDH_CLOCK_LF_XTAL_ACCURACY
    #define NRF_SDH_CLOCK_LF_XTAL_ACCURACY 1
    #endif

  • So I think (fingers crossed) this problem has gone away. I think this might have been an IAR debugger setting. We didn't have the "-drv_vector_table_base=0x0" in Debugger->Extra Options.  Apparently deselecting "Use flash loaders" and adding this works around some known issue debugging with IAR?

  • That is correct. The --drv_vector_table_base=0x0 should be present in all IAR examples in the SDK.

Related