nrf52805 production problem

[Victor A]

Hi all,
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

翻译

搜索

复制

[Susheel Nuguru]

Hi,

38 out of 1k chip to be abnormal is not good. 

From the documentation it says

@note 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

Why do you have rc_ctiv and rc_temp_ctiv double the size of recommendation?

Also, why are you using such old SDK revision on an already older nRF5SDK solution instead of using nRF Connect SDK? Have you followed this guide, it does not look like we have official support for nRF52805 on nRF5SDK based on the compatibility matrix.

[Victor A]

Thanks for your prompt reply. SDK14.2 is indeed a relatively old version, this is because many of our projects are based on SDK14.2 development, and the project is very stable. The project was modified to the low-cost nrf52805, also based on the similarity between nrf52805 and nrf52810
Therefore, based on nrf52810 application firmware project (SDK14.2 firmware code) directly modified. I'd like to confirm a few points here
1. Based on nrf52805 chip using SDK14.2 will bring compatibility problems? And then the chip is running abnormally? (Anomaly: RC crystal oscillator is not calibrated, watchdog does not work, application function is not performed)
2. For this project, I have shipped 4k nrf52805 a few months ago, but the customer did not give us similar feedback. The previous production also did not give us feedback on this problem.
3. I can see from the official website that Nordic has two versions of nrf52805 chip models (nRF52805 Revision 1 and nRF52805 Revision 2).
I used the first version here (nRF52805 Revision 1, -A0xx), is there any difference between the two versions?

翻译

搜索

复制

[Victor A]

Hi Susheel Nuguru，

All the equipment passed the production test and was stored for 3 months. The abnormal devices were detected by random checks in these devices. The phenomenon of all abnormal devices is like a crash, it does not work at all, and the key function does not work at all. Re-energizing can bring it back to normal.After that, anomalies are hard to reproduce.

We tested and reviewed the documentation and found the following:
1. Comparing the abnormal and normal devices, it is found that the RC oscillator calibration is different between the two devices. The normal device can collect the pulse of the high frequency crystal oscillator when the RC oscillator is being calibrated. The abnormal equipment can not see the pulse of high frequency crystal oscillator for a long time test. According to the firmware Settings, the crystal calibration interval should be between 8-32s.We are wondering why the crystal oscillator will not be calibrated？

2. Another strange phenomenon is that the watchdog is not working. The firmware has a watchdog module enabled. Reset after 30s without feeding. However, after a long time test, we can not see the high-frequency crystal pulse when reading and writing flash after software reset (the firmware will read and write parameters in flash at the beginning). Why is the watchdog not working? Is the RC oscillator not working at all?

3. As for the chip, we used model nrf52805-CAAAA0. This chip showed an exception in the data, and the CPU could not wake up normally. We didn't use the SPIM functionality, but the anomalies were similar.

Could you please help answer the questions I raised above and provide some ways for us to continue to verify the cause of the problem

翻译

搜索

复制

[Susheel Nuguru]

Hi Zheng,

Victor A said:

Re-energizing can bring it back to normal.After that, anomalies are hard to reproduce.

I assume that by Re-energizing, you mean by power off-on cycle? 

This one looks like a case for the Quality team. Is it possible for you to post the boards to us so that the Quality team can take over? We need to find a way to reproduce those here on the chips you mentioned so that we can help you explain what the issue is. Without exact steps on how to reproduce or if it is not possible for us to reproduce, it is hard for the Quality team to help or assist you.