sd_flash_page_erase cause hardfault

[sean]

hi,

    We are currently having some problems erasing flash，The problem recurrence rate was 1%，the recurrence rate of specify chip problems is 100%，Here are some scenarios as flow.Windows/KEIL/SDK17.0.2

---------scenarios 1--------------

sd_softdevice_enable()      return NRF_SUCCESS
sd_flash_page_erase()     return NRF_SUCCESS

wating sd_flash_page_erase()  event    --> cause hardfault
sd_ble_cfg_set()
sd_ble_enable() 

advertising_init()

->Problems occur, specify chip  100% recurrence rate

-----------scenarios 2----------------------

sd_softdevice_enable()         return NRF_SUCCESS

nrf_delay_ms(100)
sd_flash_page_erase()        return NRF_SUCCESS

wating sd_flash_page_erase()  event
sd_ble_cfg_set()
sd_ble_enable() 

advertising_init()

-> specify chip Problems disappear

-----------scenarios 3----------------------

sd_softdevice_enable()       return NRF_SUCCESS

sd_ble_cfg_set()
sd_ble_enable() 

sd_flash_page_erase()       return NRF_SUCCESS

wating sd_flash_page_erase()  event

advertising_init()

-> specify chip Problems disappear

[Vidar Berg]

Hello,

Does the program enter the HardFault_Handler() function, or does it go into the user specified fault handler that is registered when you call sd_softdevice_enable()? Could you include a screenshot showing the call stack and cpu registers after you have entered one of these fault handlers?

Thanks,

Vidar

[sean]

hi，

   it go into the user specified fault handler，As shown below.

 

call stack and cpu registers

If  need any more information let me know.

[Vidar Berg]

Hi,

Thanks for confirming. What you are seeing is a Softdevice assertion (Error handling). I will look into what may causing this assert, but first I need to know what nRF52 and Softdevice variant you are using.

[sean]

hi，

 nRF52833.    Softdevice:   s140_nrf52_7.0.1_softdevice

[Vidar Berg]

Hi,

Are you using the internal RC oscillator or the crystal oscillator as the low frequency clock source?

Thanks,

Vidar

[sean]

hi，

   internal RC as the low frequency clock source

[Vidar Berg]

Hi,

OK, thanks. This assertion you are getting indicates that the page erase operation took more time than the Softdevice anticipated. The question is if the erase really took to long to perform in HW, or if the Softdevice just failed to time the operation correctly due to LF clock drift.

To help narrow down the problem, could you please repeat the test with the LFSYNTH?

You can use the configurations below for this test:

// </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 2
#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 0
#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 0
#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 7
#endif

[sean]

Hi，

    The problem was solved，What's wrong will with this change？

[Vidar Berg]

Hi,

Thanks for confirming. So it seems like the issue may be that the Softdevice is not adding enough margin to account for the additional clock drift from the RC oscillator. The LFSYNTH is derived from the HF crystal oscillator (HFXO) and is therefore offering a better clock accuracy. I will discuss with the team to see if they agree with my assumptions and get back to you.

Please note that we do not recommend using the LFSYNTH for production FW. It has a negative impact on the current consumption as it forces the HFXO to stay on in sleep.