MPSL Assert 109, 496

RE: MPSL Assert 109, 496

Vidar Berg — Tue, 18 Feb 2025 16:15:27 GMT

It appears to be a division error caused by CONFIG_SYS_CLOCK_TICKS_PER_SEC being set to '1000' instead of the default '32768' value in this project. Commenting this line in the prj.conf file made the problem go away. I will check with the team why this was added in the first place. Git history shows it has been there from the start.

RE: MPSL Assert 109, 496

nrbrook — Tue, 04 Feb 2025 13:09:33 GMT

I can confirm your example works correctly. However, it doesn't in nRF Desktop. Modify main.c as shown:

#include <app_event_manager.h>

#define MODULE main
#include <caf/events/module_state_event.h>

#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(MODULE);

static struct k_work_delayable delay_work;

static void delay_work_handler(struct k_work *work)
{
	int64_t current_time = k_uptime_get();
    {
        int16_t ms = current_time % MSEC_PER_SEC;
        int16_t s = (current_time / MSEC_PER_SEC) % SEC_PER_MIN;
        int16_t m = (current_time / (MSEC_PER_SEC * SEC_PER_MIN)) % MIN_PER_HOUR;
        int16_t h = current_time / (MSEC_PER_SEC * SEC_PER_MIN * MIN_PER_HOUR);
        LOG_INF("Current time: %02u:%02u:%02u.%03u", h, m, s, ms);
    }
}

int main(void)
{
	if (app_event_manager_init()) {
		LOG_ERR("Application Event Manager not initialized");
	} else {
		module_set_state(MODULE_STATE_READY);
	}

	int64_t current_time = k_uptime_get();
    {
        int16_t ms = current_time % MSEC_PER_SEC;
        int16_t s = (current_time / MSEC_PER_SEC) % SEC_PER_MIN;
        int16_t m = (current_time / (MSEC_PER_SEC * SEC_PER_MIN)) % MIN_PER_HOUR;
        int16_t h = current_time / (MSEC_PER_SEC * SEC_PER_MIN * MIN_PER_HOUR);
        LOG_INF("Current time: %02u:%02u:%02u.%03u", h, m, s, ms);
    }

	k_work_init_delayable(&delay_work, delay_work_handler);
	k_work_schedule(&delay_work, K_SECONDS(60));

	return 0;
}

Result:

[00:00:00.004,821] <inf> main: Current time: 00:00:00.004
...
[00:00:58.598,693] <inf> main: Current time: 00:01:00.005

RE: MPSL Assert 109, 496

Vidar Berg — Thu, 30 Jan 2025 13:18:02 GMT

Thank you for the code snippets. Unfortunately, I have not managed to reproduce the issue here. Both are using the kernel's system clock (RTC) to produce timestamps. Here is the project I used for test:

devzone.nordicsemi.com/.../4263.timestamp_5F00_test.zip

Were you able to reproduce this with any of the SDK samples?

RE: MPSL Assert 109, 496

nrbrook — Wed, 22 Jan 2025 14:49:30 GMT

Thanks for your responses.

To assist reproduction of the timestamp issue, here is the code to print the timestamps:

static struct k_work_delayable power_off_timeout_work;

static void power_off_timeout(struct k_work *work) {
    LOG_WRN("Power off timeout");
    int64_t current_time = k_uptime_get();
    {
        int16_t ms = current_time % MSEC_PER_SEC;
        int16_t s = (current_time / MSEC_PER_SEC) % SEC_PER_MIN;
        int16_t m = (current_time / (MSEC_PER_SEC * SEC_PER_MIN)) % MIN_PER_HOUR;
        int16_t h = current_time / (MSEC_PER_SEC * SEC_PER_MIN * MIN_PER_HOUR);
        LOG_DBG("Current time: %02u:%02u:%02u.%03u", h, m, s, ms);
    }
}

static void reschedule_power_off_after(uint32_t delay_s) {
    int64_t current_time = k_uptime_get();
    {
        int16_t ms = current_time % MSEC_PER_SEC;
        int16_t s = (current_time / MSEC_PER_SEC) % SEC_PER_MIN;
        int16_t m = (current_time / (MSEC_PER_SEC * SEC_PER_MIN)) % MIN_PER_HOUR;
        int16_t h = current_time / (MSEC_PER_SEC * SEC_PER_MIN * MIN_PER_HOUR);
        LOG_DBG("Current time: %02u:%02u:%02u.%03u", h, m, s, ms);
    }
    int64_t completed_time = current_time + delay_s * MSEC_PER_SEC;
    int16_t ms = completed_time % MSEC_PER_SEC;
    int16_t s = (completed_time / MSEC_PER_SEC) % SEC_PER_MIN;
    int16_t m = (completed_time / (MSEC_PER_SEC * SEC_PER_MIN)) % MIN_PER_HOUR;
    int16_t h = completed_time / (MSEC_PER_SEC * SEC_PER_MIN * MIN_PER_HOUR);
    LOG_DBG("Rescheduling power off timeout in %d seconds at %02u:%02u:%02u.%03u", delay_s, h, m, s, ms);
    k_work_reschedule(&power_off_timeout_work, K_SECONDS(delay_s));
}

RE: MPSL Assert 109, 496

Vidar Berg — Wed, 22 Jan 2025 14:44:45 GMT

The issue seems to be that LF clock calibration events fails to be configured properly when the bootloader and the application select different LF clock sources (LFXO and LFRC). The MPSL team is looking into this. If you plan to use the RC oscillator, it is best to set it as the default clock source in your board file. That way it will default to the same clock source for other FW images such as bootloader.

[quote user="nrbrook"]In what cases would I want to enable "CONFIG_SYSTEM_CLOCK_WAIT_FOR_STABILITY"?[/quote]

This is the default option, but I can't think of a good example where it is strictly required. There are some samples which enables SYSTEM_CLOCK_NO_WAIT to reduce the startup time. MPSL will ensure LFXO is running, or LFRC is calibrated before BLE is started.

[quote user="nrbrook"]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.[/quote]

It should be sufficient to enable CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC. CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION is automatically enabled when the RC osc. is selected.

[quote user="nrbrook"]How can I ensure the firmware reboots on MPSL assert?[/quote]

CONFIG_RESET_ON_FATAL_ERROR=y

[quote user="nrbrook"]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:[/quote]

I'm not sure about this. I thought both were using the same system clock. I need to see if I can reproduce this.

RE: MPSL Assert 109, 496

nrbrook — Wed, 22 Jan 2025 07:05:10 GMT

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.

RE: MPSL Assert 109, 496

Vidar Berg — Wed, 22 Jan 2025 06:39:01 GMT

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?

RE: MPSL Assert 109, 496

nrbrook — Tue, 21 Jan 2025 18:11:36 GMT

It seems to work ok when using the external crystal.

RE: MPSL Assert 109, 496

nrbrook — Tue, 21 Jan 2025 14:22:33 GMT

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.

RE: MPSL Assert 109, 496

Vidar Berg — Tue, 21 Jan 2025 13:37:38 GMT

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.