After running for a period of time (about 10 days), some devices do not work

Some of the products we produce do not work after about 10 days.
Our firmware starts the watchdog module as soon as it starts, and sets the timeout period to 30s.
And read and write parameters stored in the flash.
After that, initialize the RC crystal, run the application, go to sleep mode, and wake up with app_timer

After testing, we found some specific phenomena:
1. The normal equipment can collect the pulse signal of the high frequency crystal oscillator when RC crystal oscillator is calibrated.
The abnormal device can not collect the high frequency crystal pulse signal
2. If a program problem causes a crash, the watchdog should restart after 30 seconds, and the working pulse signal of the high-frequency crystal oscillator when reading and writing the flash can be seen, but the abnormal device cannot collect it.This means the watchdog is not working.

We suspect that the program does not run because the RC crystal oscillator does not work. Would you like to know what causes the RC crystal oscillator to not work during the normal operation of the program

翻译

搜索

复制

翻译

搜索

复制

Parents
  • I used NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_8000MS_CALIBRATION.

    If the temperature remains unchanged and the RC oscillator is not calibrated for a long time, is there a risk that the RC oscillator will stop working

  • Hi,

    Victor A said:
    If the temperature remains unchanged and the RC oscillator is not calibrated for a long time, is there a risk that the RC oscillator will stop working

    It's not impossible, but not highly likely. But yes, if the temperature remains unchanged and the RC oscillator is not calibrated for a long time it can lead to a slight drift in the RC oscillator’s frequency, which can affect the accuracy and functionality and in turn cause issues in wake-up times and the watchdog. 

    Maybe try increasing the calibration frequency to, say, every 2000ms? And also ensure that the LFCLK is properly initialised before you start the peripherals. Also, using an external crystal can provide more stability than the RC oscillator.

    -Priyanka

Reply
  • Hi,

    Victor A said:
    If the temperature remains unchanged and the RC oscillator is not calibrated for a long time, is there a risk that the RC oscillator will stop working

    It's not impossible, but not highly likely. But yes, if the temperature remains unchanged and the RC oscillator is not calibrated for a long time it can lead to a slight drift in the RC oscillator’s frequency, which can affect the accuracy and functionality and in turn cause issues in wake-up times and the watchdog. 

    Maybe try increasing the calibration frequency to, say, every 2000ms? And also ensure that the LFCLK is properly initialised before you start the peripherals. Also, using an external crystal can provide more stability than the RC oscillator.

    -Priyanka

Children
  • which can affect the accuracy and functionality and in turn cause issues in wake-up times and the watchdog. 

    Does this mean that the RC oscillator stops working, or does the frequency drift?

  • nrf_clock_lf_cfg_t const clock_lf_RC =
        {
            .source        = NRF_CLOCK_LF_SRC_RC,
            .rc_ctiv       = 32, //NRF_SDH_CLOCK_LF_RC_CTIV,
            .rc_temp_ctiv  = 4,  //NRF_SDH_CLOCK_LF_RC_TEMP_CTIV,
    #ifdef S140
            .xtal_accuracy = 0   //NRF_SDH_CLOCK_LF_XTAL_ACCURACY
    #else
            .accuracy      = 0//   NRF_SDH_CLOCK_LF_XTAL_ACCURACY
    #endif
        };

    Hi Priyanka

    If the above configuration is followed, is it possible that the RC oscillator will stop working?

    Another question, we used 52810 device file to compile, will there be problems downloading to 52805?

  • Hi,

    Victor A said:
    If the above configuration is followed, is it possible that the RC oscillator will stop working?

    I can see that your values for rc_ctiv and rc_temp_ctiv are different from the default values (16 and 2 respectively) which means that in your case, the calibration happens less frequently than defaults . I am not sure whether this is an issue, though. I will just check this internally with and expert and get back to you.

    Victor A said:
    we used 52810 device file to compile, will there be problems downloading to 52805?

    We always recommend compiling for the SoC that you are using, since though they might be similar, the memory mapping, peripheral support etc are quite different. You an take a look at this guide on developing for the nRF52805.

    -Priyanka

  • I can see that your values for rc_ctiv and rc_temp_ctiv are different from the default values (16 and 2 respectively) which means that in your case, the calibration happens less frequently than defaults . I am not sure whether this is an issue, though. I will just check this internally with and expert and get back to you.

    Thank you very much. I am looking forward to your reply

    This will be very helpful to us

  • The firmware of 52805 is ported from the other firmware of 52810. This firmware of 52810 has been released for several years, and the application is very stable.The firmware of 52810 does not have the same non-working phenomenon as The firmware of 52805

    The SDK version is SDK_14.2.0, and the softdevice version is S112_V5.1.0. I have changed the.h file related to 52810 to the.h file related to 52805, and modified the definition of GPIO. The startup file is not changed, and 52810 is used. Will this cause the equipment to run abnormally after a long time running? If yes what are the easy ways to fix it

Related