All interrupt seems to be triggered twice ?

RE: All interrupt seems to be triggered twice ?

Edvin — Fri, 15 Jan 2021 13:04:24 GMT

I can't pinpoint exactly why, but it has to do with the CPU Usage check. Try to disable the NRF_PWR_MGMT_CONFIG_CPU_USAGE_MONITOR_ENABLED in sdk_config.h.

BR,

Edvin

RE: All interrupt seems to be triggered twice ?

Salmat — Thu, 14 Jan 2021 23:38:08 GMT

Hi,

Thanks for the response !

It seems to work.
In fact, it is the exact same code as in nrf_pwr_mgmt_run without CRITICAL_REGION_ENTER / EXIT.

I imagine it was there for something ! I would remove it if I understand why it was there in the first place ...
Neither I understand why critical region is waking ?

Regards,
Matt

RE: All interrupt seems to be triggered twice ?

Edvin — Thu, 14 Jan 2021 08:15:15 GMT

Hello,

It looks like it is actually CRITICAL_REGION_ENTER() and CRITICAL_REGION_EXIT() that triggers the main loop one extra time. These are being called inside nrf_pwr_mgmt_run();

If you want to skip the whole nrf_pwr_mgmt_run(), you can replace it with:

    // Wait for an event.
#ifdef SOFTDEVICE_PRESENT
    if (nrf_sdh_is_enabled())
    {
        ret_code_t ret_code = sd_app_evt_wait();
        ASSERT((ret_code == NRF_SUCCESS) || (ret_code == NRF_ERROR_SOFTDEVICE_NOT_ENABLED));
        UNUSED_VARIABLE(ret_code);
    }
    else
#endif // SOFTDEVICE_PRESENT
    {
        // Wait for an event.
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }

Best regards,

Edvin

RE: All interrupt seems to be triggered twice ?

Salmat — Fri, 08 Jan 2021 17:14:14 GMT

I am not talking at all about app_timer. I have just done an example with App_timer, but it is not only en app_timer problem.
It is the same with any interrupt !

By the way I am not using app timer scheduler at all : #define APP_TIMER_CONFIG_USE_SCHEDULER 0

Regard

RE: All interrupt seems to be triggered twice ?

Edvin — Fri, 08 Jan 2021 16:36:32 GMT

[quote user="salmat"]I have looked the source files, and for me all the app_timer functions are taking care of configurations in "rtc_irq" in "app_timer2.c" ... gaving the hand to the user handler, but all in the same irq level ![/quote]

Remember that the app_timer has it's own scheculer. All the tasks of the app timer is not necessarily done by the time you reach main(), and some may be handled later.

I have not researched this exact question before, but similar. When customers are starting and stopping the app timer in the main loop they ask why the device never goes to sleep. The answer has always been that the app timer's scheduler is woken up. Then they started a new app_timer in the main context, and stopped it when some work was done. The stop call then triggered an event in the app timer scheduler that woke the device up again.

Now, in your case, that is not an issue, because you don't start/stop any app timers from your main loop, but what I am saying is that it is the app timer that wakes up the CPU from time to time.

Best regards,

Edvin

RE: All interrupt seems to be triggered twice ?

Salmat — Fri, 08 Jan 2021 15:49:23 GMT

I have looked the source files, and for me all the app_timer functions are taking care of configurations in "rtc_irq" in "app_timer2.c" ... gaving the hand to the user handler, but all in the same irq level !
As does nrfx_spim_XXX_irq_handler, and nrfx_gpiote_irq_handler ...

I am also nearly sure it is not only going to the main loop, but going to sleep, and so processing 2 times all what is in the main loop for all wanted interrupts. Also waking two time from sleep, ...
Doing it two times is not what we want, and is a waste of processing time, and so power ...

What I think is making it sometime 202, is the processing and print of : "<info> pwr_mgmt: CPU Usage: 0%", that is also using app timer one time per seconds ! I am calling it 100 times per seconds.

Regards,
Matt

RE: All interrupt seems to be triggered twice ?

Edvin — Fri, 08 Jan 2021 14:00:01 GMT

So your main loop is called twice as often as your timer handler, that is what you are saying, right?

Without being able to pinpoint exactly what's causing this, I would say that this is not something you need to worry about.

You can dig a bit to see if you can figure out exactly what happens, but my guess is:

Your timeout handler is triggered, causing your timer_handler_count to increment.

This triggers your main loop when the timer handler is done.

After this (but probably scheduled before) the app_timer needs to do some internal work to set up the timeout register value for your next timeout. This also triggers the main_loop.

From time to time, you can see that there is 202. It may be the RTC (app_timer) that rolls over, and it requires a few extra operations to set up the next timeout.

Best regards,

Edvin