Firmware crash in mpsl_timeslot_request()

[PhilDixon]

We have recently switched to using the nRF Connect SDK. Our application is based on the "Peripheral LBS" example, and after several iterations, the code has started crashing within function mpsl_timeslot_request() during the BLE stack initialisation.

I have looked for other tickets with similar symptoms, notably this one:  RE: nRF52 DK - Peripheral UART example unmodified fails if CONFIG_BT_SERVICES is enabled. , which is a good match for what we are seeing. However, although there is a suggestion that what I am seeing is a known issue, there is no resolution described in that ticket.

In summary:

• If the device is completely erased before programming, the application will crash somewhere inside mpsl_timeslot_request().
• If I program (and run) the device with some other example code, and *then* program and run our app (without doing a full erase), it will be fine.
• This applies to SDK versions 2.1.1 (as with the ticket linked above) and *also* with SDK 2.0.2

I have also tried the following:

• Erase, program and run a known-good (example) app, such as the basic "Peripheral LBS".
• Read back the flash content, and extract the region between 0x7a000 and 0x7afff, i.e. the settings region.
• Erase, program and run our app, which will fail as described.
• Program (without erasing anything) the settings region extracted above.
• Reset; our app will now run correctly.

I have switched over to SDK 2.3.1-rc1, and this appears to cure the issue.

Can you confirm that this issue has indeed been addressed in 2.3.1? At the moment I cannot tell whether the "fix" is real, or just down to luck relating to memory layout, stack usage or similar.

Also - is there a time-scale for deciding whether this release candidate will be a full release?

Thanks,

Phil Dixon.

[PhilDixon]

Apologies - the latest version of SDK that we are using is 2.3.0-rc1, and not 2.3.1-rc1 as stated.

Phil.

[Hieu]

Hi Phil,

As you can find out from the latest reply in the case you linked, the conversation following this reply from Susheel in particular, the root cause of the issue is a stack overflow, which leads the code running where it should not, and behave how it is not meant to.

If you are certain your issue is of the same nature, then mpsl_timeslot_request() is probably not the root cause; and the workaround with flashing a different application first probably only changes how the corrupted flow runs.

I am working from home for a few days, and don't have a suitable hardware to reproduce that stack overflow issue well. With what hardware did you encounter the issue?

However, your main interest is probably whether this issue has been fixed in NCS v2.3.0-rc1 (and therefore would be in NCS v2.3.0).

Can you confirm that this issue has indeed been addressed in 2.3.1? At the moment I cannot tell whether the "fix" is real, or just down to luck relating to memory layout, stack usage or similar.

I see that the GitHub issue linked in Susheel's post was fixed on Zephyr RTOS upstream on Feb 22, but that fix doesn't seem to be included in NCS sdk-zephyr downstream yet.

Nonetheless, I will check with my internal contacts who worked with me in the same case above; and I will attempt to reproduce it with what I have.
I will get back with information latest by the end of Thu Mar 2.

Also - is there a time-scale for deciding whether this release candidate will be a full release?

We cannot comment about release date on DevZone. You can get a general sense from the time between previous versions' RC1 and official release, but please don't consider that a promise. Your Regional Sales Manager might be able to help you with this interest. Please let me know if you need a contact point.

Hieu

[PhilDixon]

Hieu,

Thanks for the response.

The reference to mpsl_timeslot_request() was simply the last point to where I could track the code; the source code for this function is not provided in the SDK. The code runs to a call to that function, but never returns from it.

The code is running on an nRF52832 DK board.

Thanks again, and I look forward to further information.

Phil.

[Hieu]

Phil,

Just updating you that I was able to contact our internal team and they are looking at it. From what we have known, it is not certain it is the same problem with the Peripheral UART DevZone thread, where the stack size is the problem.

Could you please share an example where the issue happens? It would be a lot better if we can reproduce it and get to debugging.
If you cannot strip out the confidential details, please see if you can guide us through what you have updated on top of Peripheral LBS to reproduce the problem.

Hieu

[PhilDixon]

Hieu,

A similar problem occurred with SDK 2.3.1, and I fixed it by increasing the main stack size.

I have reverted to the older SDK 2.1.1, and increasing the main stack size also fixes that case!

Thanks for your help, and sorry to take up your time.

Phil.