What is a reason of the definite SoftDevice assertion handler: m_line_num: 811; m_p_file_name: src\ll_lm.s0.c

[hardware-dept]

Hello,

We start using of our BLE devices with more or less permanent connection with our central BLE device, it was needed for Alisa connection.

BLE peripherals are old enough devices with SoftDevice S110 v7.0.0 SDK v6.0.0 on nrf51822AA, they are already in production state (that is why we can not change SoftDevice version to more newer).
Central is like a gateway from WiFi to Blutooth and vise versa. (BLE part is on nrf52832AA, S132 v2.0.0, SDK v11.0.0) 

And we found out some troubles of peripherals (resets, hangings) only after we started usage that configuration with permanent connection.
But really there are a lot of BLE disconnections with subsequent recovery a connection (we saw that with RTT Viewer). Then we deepened into the bug problem, and found out the following bug text inside our peripherals:

m_line_num: 811; m_p_file_name: src\ll_lm.s0.c

That was produced by SoftDevice assertion handler.
It was confirmed a few times on two various types of our peripheral BLE devices. To reproduce this bug we were waiting a lot of time (during a few days). 
Also we supposed, that the bug arises at the moments of connection event time.

Q: What is an exact reason of that bug text, and what are your recommnedations in our situation?

Thank you in advance.

[hardware-dept]

Not Central device had HardFault, but Peripheral as I wrote earlier in my first message. And a result of that is Reset of Peripheral.
Sorry for not so detailed my previous message. 
And I checked the accuracy at Peripheral:
NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION
Can this option be a cause of the resets?

... (Several hours passed)

Again it was reproduced the same reason: m_line_num: 811; m_p_file_name: src\ll_lm.s0.c 
It was in Peripheral (not in Central).

So, now

In central : .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM

In peripheral: NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION

But SoftDevice exception arised.

What is the next step for us?

[Kenneth]

Hi, from the initial case description I got the impression that you cannot do changes to the peripheral, but now I get the impression you can?

If that is the case, then I recommend to update from s110v7.0 -> s110v7.3, the "only" thing you need to do is:

1. Download S110v7.3 from https://www.nordicsemi.com/Software-and-Tools/Software/S110/Download#infotabs
2. Program the S110v7.3 softdevice
3. Replace the S110v7.0 with S110v7.3 header files in \SDKfolder\nrf51822\Include\s110
4. Recompile the application (with the updated header files)
5. Program the application

[hardware-dept]

Hi,
your impression is right, but only in part. We can update the considered our client products (peripherals) by OTA only in application part. Unfortunately, SoftDevice is not possible to update by OTA (because it was not provided for those old versions of our firmware). If it were possible, we would not ask you for the recommendations... May be I had to explain that details earlier, sorry.
So, we can change the lfclk accuracy at our Peripherals and any things in our application, but not the SoftDevice.  :( 
Could you advice something in our situation? Really asking...

Sincerely yours

[Kenneth]

Thanks for the clarification, I do believe that the issue here is due to a known issue that was fixed in v7.3. There really isn't much that can be done by the application if this case, but if I were you I would for testing:

1. Verify that v7.3 actually fixes the issue (to confirm the issue)

2. Try with a slightly more relaxed tolerance of the lfclk (500ppm), since that is really the only parameter you may tune for this issue

[hardware-dept]

Thank you Kenneth,

We thought about point 1 too. And we will test that during this weekend.
But I double checked the possibility to change clock accuracy to 500ppm at peripherals, and unfortunately nrf51 internal RC generator has the only option value 250ppm with various time calibration intervals from 250ms (its our project value) to 8s (or temperature check 16s). Accuracy 500ppm is possible only with external crystal. But our peripherals have not this external crystal, only our central device has the external 32.768 kHz. Anyway we will test. I don't know what is influence of different time calibration intervals, that is why we keep use the NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION (at peripherals).

...

Passed 2 hours. 

Catched:

m_line_num: 789; m_p_file_name: src\ll_lm.s0.c

So, for SD v7.3.0 the assertion line is changed from 811 (for SD v7.0.0) to 789 (for SD v7.3.0)

...

Weekend passed.
We have reproduced assert handler (SD v7.3.0) from two different types of our Peripheral devices with the same text:
m_line_num: 789; m_p_file_name: src\ll_lm.s0.c

 

What does it mean?

Best regards