MPSL Assert 109, 496

[nrbrook]

I am developing an application based on nRF desktop, SDK 2.9.0. In normal build it works as expected. In release build, which includes MCUMgr/MCUBoot and no logging or asserts (which are the only differences, and which work normally), after ~30m connected to my iPhone I get "MPSL ASSERT: 109, 496". I'm not using multiple radio protocols, and I've not fundamentally altered the application in a way that I can think would cause an MPSL error. Nothing should happen after 30m – there are no timeouts that occur, and nothing happens in the debug build. I am using nRF52832, so I modified the nRF52kb configuration. What could be causing that error?

[Vidar Berg]

Hello,

I don’t think I’ve seen any reports of this exact assertion before. If it’s possible to start a debug session before or after the assertion is raised, could you please post a picture of the call stack? The developers were interested in having a look at the backtrace.

Best regards,

Vidar

Edit: they were also wondering if you were using bt_disable() in your app and if you are using the internal RC oscillator as your LF clock source.

[nrbrook]

Yes I am using the RC oscillator, because that config was copied from the keyboard. However, the board does actually have an external crystal I could use.

I have not added bt_disable() and it doesn't look like it was used by nrf_desktop anywhere.

Stack trace attached.

[nrbrook]

It seems to work ok when using the external crystal.

[Vidar Berg]

Thanks for confirming that it works. We will continue to investigate why it is asserting with the LFRC. Will you use the external crystal in your final design?

[nrbrook]

Yes on this one, but perhaps not on all board designs.

A few tangential questions:

• In what cases would I want to enable "CONFIG_SYSTEM_CLOCK_WAIT_FOR_STABILITY"?
• Should I be modifying any other configuration to ensure the RC oscillator does not get out of sync? Existing boards e.g. nRF52DK and nRF52kbd don't seem to.
• How can I ensure the firmware reboots on MPSL assert?
• Possibly also related: delayed work (using k_work_reschedule) seems to be submitted before expected when compared to the log timestamp. This happens even with XTAL. For example:
  

  [00:00:06.782,836] <dbg> idle_power_off: reschedule_power_off_after: Current time: 00:00:06.945
  [00:00:06.782,867] <dbg> idle_power_off: reschedule_power_off_after: Rescheduling power off timeout in 60 seconds at 00:01:06.945
  ...
  [00:01:05.377,014] <dbg> idle_power_off: power_off_timeout: Current time: 00:01:06.946

  While the current time from k_uptime_get() indicates the delay is correct, the log timestamps do not have the same time difference.