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!

[Edvin]

Hello,

The error isn't populated when the id is a softdevice assert. The same goes for the file name and line number.

What SoftDevice are you using? S112? S132?

Are you using any other protocols in addition to BLE? If so, which ones? Or do you use the Timeslot API?

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

Was this the change that you did that lead to the softdevice assert? Are you able to detect during what API the assert occurs?

Best regards,

Edvin

[Will]

Firstly, we used the protocol stack of S112. In order to better verify the issue, we directly used the ble_app_uart demo of the SDK, and the modification points have been explained.

Secondly, regarding the clock configuration modification, we verified that it was ok. We have produced many products, but only one set of products had the above-mentioned issues.

Finally, we are not sure which API caused the assertion error, as it occurred in the protocol stack.

If you have anything you want to verify, please let me know. Thank you!

[Edvin]

Will said:

Finally, we are not sure which API caused the assertion error, as it occurred in the protocol stack.

What I meant was that you can try debugging, adding lines of logs or setting breakpoints (remember to reset the application every time you hit a breakpoint), to figure out the last softdevice call (sd_...()) that was called before the assertion occured.

Based on the log, it may look like it is in the very beginning. Does it happen at one of these?

nrf_sdh_ble_default_cfg_set()

nrf_sdh_ble_default_cfg_set()

nrf_sdh_ble_enable()?

If you try to set breakpoints directly before and after these, which ones are reached?

Is there some way for me to reproduce what you are seeing on a DK?

Best regards,

Edvin

[Will]

The probability of this problem occurring is relatively small.

We speculate that there may be a problem with the chip's external devices or internal power supply, causing the protocol stack to have an assertion error, as this error occurred after calling the enable broadcast interface.

Is there a way to obtain the PC pointer when an error occurs through JLINK? so that the problem can be located more quickly.

We need to identify the root cause of this issue so that we can screen out problematic products during subsequent production.

[Edvin]

Oh, so it doesn't happen every time you boot up? 

Ok, so 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?

I will check with the softdevice controller team if they have any input (I don't have the source code for the softdevice). 

But 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?

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?

Best regards,

Edvin

[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