nrf52840 central role overnight crashes

[spencersmith]

nRF52840 SoftDevice S140 7.3.0. nRF5_SDK_17.1.0_ddde560. IAR for ARM 9.32.1.

Central Role managing 16 connections to Peripherals together with USB communication to a PC.

Seeing resets on overnight test runs. Typically need to have all 16 connections active to make this happen consistently but have been observed with fewer.

Typically call stack with a jlink debugger is empty and the memory locations are for the SoftDevice section.

On reset the function app_error_fault_handler() is called with the parameters id: 0x1, pc: 0x14c24, info: 0x0. app_error_fault_handler() is passed these same values when this occurs.

 

Any help on troubleshooting this further would be much appreciated.

[Sigurd]

Hi!

With id:0x01 and info:0, this indicates a SoftDevice assert. https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.3.0/group___n_r_f___f_a_u_l_t___i_d_s.html?cp=5_7_4_1_2_8_0_2_1#ga3884a419c2f90d294672e79711d009bf

But, I don't see any assert that can happen at pc 0x14c24 on S140 v7.3.0

Are you sure that you are using S140 v7.3.0 ? Also, does the pc value change each time this happens, or is it always 0x14c24 ?

[spencersmith]

In process of migrating from S140 v7.2.0 to v7.3.0. Thought this should be v7.3.0 but will double check. Have seen this same pc address several times.

Trying to catch more of these with NRF_LOG RTT enabled. Hoping this doesn’t change performance and has additional debug information.

Still using the default app_error_fault_handler() in the SDK but might need a custom one. Would it be possible to reset only the SoftDevice instead of resetting everything on a SoftDevice assertion error?

[Sigurd]

spencersmith said:

In process of migrating from S140 v7.2.0 to v7.3.0. Thought this should be v7.3.0 but will double check. Have seen this same pc address several times.

Thanks for this info. 14c24 is a valid assert on S140 v7.2.0, so it must have been that version you are using then. I'm looking into more information on this assert now.

[Sigurd]

Hi!

Are you also running scanner while managing 16 connections, or start scanning when a link is lost?

Edit: In order to reproduce this, we would also like some more information about your test-setup, e.g. what connection interval, latency, scan/ext-scan interval/window, etc. you are using, and if you are using any nRF5-SDK examples in your test ?

[spencersmith]

pc 0x14c24 was for S140 v7.2.0. Thought things had switched to S140 v7.3.0 but didn't. Now doing a SD version check when the application boots up to confirm. Haven't seen any resets now after making sure v7.3.0 is being used. Still need to get more runtime to know for sure.

Do you expect the 0x14c24 assertion to also be present in S140 v7.3.0? Would  it just move to a different address?

30ms scan window at the same interval as the connection interval of 200ms. 1Mbps no extended. scanner never stops even after hitting capacity. custom service not using sdk examples.

[Sigurd]

spencersmith said:

Do you expect the 0x14c24 assertion to also be present in S140 v7.3.0? Would  it just move to a different address?

It will most likely move the PC value.

spencersmith said:

30ms scan window at the same interval as the connection interval of 200ms. 1Mbps no extended. scanner never stops even after hitting capacity. custom service not using sdk examples.

Thanks for this info, we will try to reproduce the issue based on this.

To rule out any HW issue on this specific device, have you tested this on several nRF52840 central devices?

[spencersmith]

Yes have tried multiple  nRF52840 boards.

Please close this ticket. We are moving forward with S140 v7.3.0 regardless. I will open something new with new information if continue to see SD assertions.