• State Not Answered
  • Replies 9 replies
  • Subscribers 68 subscribers
  • Views 263 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 332579
Options

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

Victor A

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
  • 0

    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

  • 0 in reply to Victor A

    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

  • 0 in reply to Priyanka
    Priyanka said:
    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?

  • 0 in reply to Priyanka 

    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?

  • 0 in reply to Victor A

    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

Reply
  • 0 in reply to Victor A

    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

Children
  • 0 in reply to Priyanka
    Priyanka said:
    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

    Priyanka said:
    You an take a look at this guide on developing for the nRF52805.

    This will be very helpful to us

  • 0 in reply to Priyanka

    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

  • 0 in reply to Priyanka

    Hi Priyanka,
    For this project firmware overview:
    A few months ago, we shipped 10k products and never had such problems. In the latest order, 38 out of 1k products were abnormal. The phenomenon was that the watchdog did not work and the RC oscillator failed to calibrate, and we think it may be caused by the abnormal stop of RC coscillator.
    This will bring great worries to the following orders, so I want to find out the problem fundamentally and solve it. My doubts are as follows:
    1. Prerequisite: The software sdk is S112 under 14.2 (nRF5_SDK_14.2.0_17b948a), and the chip hardware is nrf52805 (BGA package).
    I will set the device to shut down when the device is delivered, and it will be in idle mode.
    2. For products with appeal problems, I reinstall the battery, and the equipment can work normally (it has been running normally for a week now).
    3. I learned that a setting is different from the recommended setting. Due to the extreme power consumption requirements, the internal RC parameters are set as follows:

    nrf_clock_lf_cfg_t const clock_lf_cfg =
{
.source = NRF_SDH_CLOCK_LF_SRC,
.rc_ctiv = (16 * 2), //NRF_SDH_CLOCK_LF_RC_CTIV,
.rc_temp_ctiv = (2 * 2), //NRF_SDH_CLOCK_LF_RC_TEMP_CTIV,
#ifdef S140
.xtal_accuracy = 0 //NRF_SDH_CLOCK_LF_XTAL_ACCURACY
#else
.accuracy = 1,//NRF_SDH_CLOCK_LF_XTAL_ACCURACY
#endif
};

    Does this internal RC setup cause unusual problems for the device? Cause the chip to run abnormally after a period of time?
    4. If yes, is it due to the compatibility of software SDK and chip? How can I fix it?

    Since there will be a certain amount of orders in the next October, this problem needs to be solved urgently, please help to provide a solution

  • 0 in reply to Victor A

    Hi,

    It looks like you have a new ticket created on the issue, and are being assisted by an appropriate expert for the same. Kindly continue your conversation there.

    -Priyanka

Related