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

we got errror, SOFTDEVICE: ASSERTION FAILED in SDK_15.3.0 on our custom hardware based on nRF52832.

Our custom board uses internal RC clock source and I tried to build original sample app, "ble_app_pwr_profiling" in SDK 15.3.0 using attached sdk_config.h modified only with LF Clock setted to RC source. then after we go "for loop" in the main() and enter the idle_state_handle(), we got the error, "SOFTDEVICE: ASSERTION FAILED" in the app_error_fault_handler(). I attached the debug capture file below with our sdk_config.h and our schematic. please how can I why this problem occurred?

our sdk_config.h:

sdk_config.h

our schematic is as followings:

Parents
  • Hi.

    Have you made any modifications to the code?

    Can you check which value you are using for the p_clock_lf_cfg argument of the sd_softdevice_enable?

    Best regards,

    Andreas

  • I have to use internal rc osillator so i modified belows definition macro in sdk_config.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 //hong
    #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 //hong
    #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 //hong
    #endif

    // <o> NRF_SDH_CLOCK_LF_ACCURACY - External clock accuracy used in the LL to compute timing.

    // <0=> NRF_CLOCK_LF_ACCURACY_250_PPM
    // <1=> NRF_CLOCK_LF_ACCURACY_500_PPM
    // <2=> NRF_CLOCK_LF_ACCURACY_150_PPM
    // <3=> NRF_CLOCK_LF_ACCURACY_100_PPM
    // <4=> NRF_CLOCK_LF_ACCURACY_75_PPM
    // <5=> NRF_CLOCK_LF_ACCURACY_50_PPM
    // <6=> NRF_CLOCK_LF_ACCURACY_30_PPM
    // <7=> NRF_CLOCK_LF_ACCURACY_20_PPM
    // <8=> NRF_CLOCK_LF_ACCURACY_10_PPM
    // <9=> NRF_CLOCK_LF_ACCURACY_5_PPM
    // <10=> NRF_CLOCK_LF_ACCURACY_2_PPM
    // <11=> NRF_CLOCK_LF_ACCURACY_1_PPM

    #ifndef NRF_SDH_CLOCK_LF_ACCURACY
    #define NRF_SDH_CLOCK_LF_ACCURACY 1 //hong
    #endif

    As I said before, I modified from the original to my definitions in sdk_config.h.

    and when I didn't use SDH as I used the project, "peripheral\blinky", it worked well without fail-error.

  • Hi.

    Can you try to flash this file to your board: test.hex

    Do you experience the assert with this file?

    Best regards,

    Andreas

  • I just tested the test.hex you gave but we got the same asset error with the same pc value.

  • I;m sorry for the earlier test for flashing wrong. please let me know how to flash test.hex in ses env..maybe we need test.elf file for debugging purpose.

  • I just tested your test.elf and I coudn't get the assert error and it looks like our board was running right but in 3~4 minutes, it looks like we'v got the reset because on ses debuger, pc again went to the start point of main() and even if we setted the breakpoint to the start of app_error_fault_handler() in diassemly window,we couldn't meet the the breakpoint of app_error_fault_handler(). Anyway, it looks like we had a better situations.

Reply
  • I just tested your test.elf and I coudn't get the assert error and it looks like our board was running right but in 3~4 minutes, it looks like we'v got the reset because on ses debuger, pc again went to the start point of main() and even if we setted the breakpoint to the start of app_error_fault_handler() in diassemly window,we couldn't meet the the breakpoint of app_error_fault_handler(). Anyway, it looks like we had a better situations.

Children
Related