SOFTDEVICE: ASSERTION FAILED

[Will]

Dear Nordic Engineer,

Hello!

We are currently in the mass production of our products. The chip model we are using is nRF52805, and the SDK version is nRF5_SDK_15.3.0_59ac345.

Among the products in production, one set of products is experiencing a continuous reset phenomenon. In order to verify and troubleshoot this issue, we used the original ble_app_uart project in the SDK and made the following modification tests:

1. Added error log output in the app_error_fault_handler function. The specific situation is shown in the attached figure.

2. Modified the protocol stack clock configuration, and the relevant content is shown in the attached figure.

3. Compiled the modified project, burned the hex file into the chip, and the operation result is shown in the attached figure.

Since our products are in mass production, this problem has a relatively large impact on the production progress. We hope that your engineers can assist us in troubleshooting and solving this problem. Thank you very much!

If you need further information, please feel free to contact us.

Best regards!

[Will]

Q: it doesn't happen every time you boot up? 
A: For the problematic device, it can reproduce the problem every time it is powered on.

Q:you are using S112 from nRF5 SDK 15.3.0. That would make it the S112_nrf52_6.1.1_softdevice.hex (SDK\components\softdevice\s112\hex), right?
A:Yes.

Q:do you have an estimation about how often it happens? And is it only on a couple of devices? Or how large percentage would you say?
A:We have produced hundreds of thousands of devices so far, and one of them has encountered this problem.

Q:Do you see anything upon visual inspection? Any soldering that may not be done properly? Particularly around the XTALs, since it only occurs some times?
A:We can ensure that all components except for the chip are functioning properly.

Due to the time difference, our communication efficiency is relatively low. Therefore, you can inform me of the areas that need to be confirmed or debugged at once, and I will confirm and reply to you as soon as I see them. Thank you very much!

[Edvin]

Hello,

For debugging purposes, can you please try to use NRF_CLOCK_LF_SRC_SYNTH, to rule out calibration issues? Depending on exactly when the assert happens, you can also try to set NRF_SDH_CLOCK_LF_RC_TEMP_CTIV to zero, and/or reduce NRF_SDH_CLOCK_LF_RC_CTIV. It would be helpful to know if the assert happens immediately after the call to sd_ble_gap_adv_start().

On the other hand, if this issue is only present in one device, out of several hundreds of thousands, then it may be that there is a faulty device. Let me know whether setting the NRF_CLOCK_LF_SRC_SYNTH, or changing the NRF_SDH_CLOCK_LF_RC_TEMP_CTIV/NRF_SDH_CLOCK_LF_RC_CTIV makes any difference, and then we can consider sending that sample for failure analysis in our labs.

Best regards,

Edvin

[Will]

Hello Edvin,

Could you tell me more about the configuration rules or usage of NRF_CLOCK_LF_SRC_SYNTH, NRF_SDH_CLOCK_LF_RC_CTIV, and NRF_SDH_CLOCK_LF_RC_TEMP_CTIV? Since there is no high-speed crystal oscillator on my custom board, I configured the internal RC as the clock source during development.

In a single step debugging environment, the program will immediately generate an assertion error when it runs to sd-ble_gap-adv_start.