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,

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.

[Vidar Berg]

Hi,

Does the clock configuration you used originally match the one below?

// </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_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
#endif

 

NRF_SDH_CLOCK_LF_RC_CTIV and NRF_SDH_CLOCK_LF_RC_TEMP_CTIV can be set lower than what I have here, but they should not be set higher. And the accuracy shall always be set to 500 ppm.

[sean]

hi，

    NRF_SDH_CLOCK_LF_RC_CTIV   is 32，The other configuration is the same

[Vidar Berg]

Hi,

This is above the recommended value, but I do not believe it is enough to explain the assertion, unfortunately.

Here is from the Softdevice API documentation:

For nRF52, the application must ensure calibration at least once every 8 seconds to ensure +/-500 ppm clock stability. The recommended configuration for NRF_CLOCK_LF_SRC_RC on nRF52 is rc_ctiv=16 and rc_temp_ctiv=2. This will ensure calibration at least once every 8 seconds and for temperature changes of 0.5 degrees Celsius every 4 seconds. See the Product Specification for the nRF52 device being used for more information.

I'm currently working on a test application I was hoping you could run on your "bad" chip to time the flash erase. Now I'm wondering what would be the best way for you to measure this. Do you have an IO that could serve as a debug output pin and a logic analyzer to monitor its state, or would it better if I used a TIMER and printed the result out on RTT?

[sean]

hi，

    Thanks for your help. We have a solution