nRF54 `mpsl_temperature_get` hangs the MCU

[Marcus_P]

We have a common codebase with both softdevice (nRF51/52 code) and now zephyr (nRF54 code). To make our code compatible I have the following replacement to sd_temp_get. This is always called from threadmode but sometimes it freezes (WDT resets the MCU). Ive seen the comment:

@note This function must be executed in the same execution priority as @ref mpsl_low_priority_process.

but don't understand if it is the same zephyr execution priority or IRQ priority.
I don't see any special code for raising the IRQ priority when using CONFIG_TEMP_NRF5_MPSL, please advise how to get the current MCU temperature in threadmode.

static uint32_t sd_temp_get(int32_t * p_temp)
{
    *p_temp = mpsl_temperature_get();
    return 0; // NRF_SUCCESS
}

[Marcus_P]

Solved by creating a new thread that shares the same prio as MPSL low prio. Please advise if there is a better solution to do this without creating a new thread

K_THREAD_DEFINE(temperature_thread_id, TEMPERATURE_THREAD_STACK_SIZE,
                temperature_thread_entry, NULL, NULL, NULL,
                K_PRIO_COOP(CONFIG_MPSL_THREAD_COOP_PRIO), 0, 0);

[Einar Thorsrud]

Hi,

You should respect the limitations of the priority. The simplest way to achieve the same priority as mpsl_low_priority_process() is to use a workqueue in the same way as MPSL low priority process here (where you can see the priority is CONFIG_MPSL_THREAD_COOP_PRIO, which is default 8 for BLE applications). But this will then be asynchronous, and not a drop-in replacement for the sd_temp_get().

Another much simpler approach could be used if the temperature is regularly checked (either because you use LFRC where the temperature is regularly checked, or if using the LFXO because you have a thread running at the correct priority that regularly checks the temperature using the temp sensor). Then you can simply read the TEMP register directly to get the last temperature measurement (reading the TEMP sensor is allowed even if MPSL is enabled, as long as you do not write to any registers, meaning you cannot start temperature measurement this way). This approach has been discussed in this thread.