Interrupts not waking FreeRTOS up in Tickless mode

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Thu, 10 Sep 2020 12:53:02 GMT

[quote user="dfer"]any Task switch sets the Event flag with __SEV, see portYIELD macro (why? I guess SCB->ICSR = SCB_ICSR_PENDSVSET_Msk would be enough, the PendSV interrupt would be set pending and the event flag is set pending, see SEVONPEND) [/quote]

You are right. I think SEV is not needed here, but I think it is a harmless addition. SEVONPEND bit set does not need SEV to be added explicitly after pending this to ICSR.

[quote user="dfer"]So the chances that we come to vPortSuppressTicksAndSleep with the event flag already set are high. This event flag setting has happened most probably in the past and the scheduler has already served the necessary task switches. [/quote]

Agreed...

[quote user="dfer"]After this, a masked application interrupt sets the event flag but the ISR is not executed. [/quote]

Agreed, because of SEVONPEND.

[quote user="dfer"]After sd_nvic_critical_region_enter, the function eTaskConfirmSleepModeStatus is called, which will abort the sleep process if a task or a task switch is pending (see served ISR above(*) ) - so here I see no problems.[/quote]

Agreed.

[quote user="dfer"]If an interrupt happens after eTaskConfirmSleepModeStatus, it will set the event flag and the next WFE will be skipped - here I see no problem.[/quote]

Agreed.

[quote user="dfer"]If an interrupt occurs after WFE, the normal wake up prcedure will happen and again here I see no problems.[/quote]

Agreed.

i agree with you Davide, i missed to see the check eTaskConfirmSleepModeStatus. Should be safe to clear the event just before entering the critical section.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Wed, 09 Sep 2020 14:32:40 GMT

I feel we are a bit drifting from each other away.

So to recap:

any Task switch sets the Event flag with __SEV, see portYIELD macro (why? I guess SCB->ICSR = SCB_ICSR_PENDSVSET_Msk would be enough, the PendSV interrupt would be set pending and the event flag is set pending, see SEVONPEND)

the tick interrupt sets the event flag with __SEV (why? see comment above)

any Interrupt sets the Event flag automatically (see SEVONPEND)

So the chances that we come to vPortSuppressTicksAndSleep with the event flag already set are high. This event flag setting has happened most probably in the past and the scheduler has already served the necessary task switches.

Now, resetting the event flag before the sd_nvic_critical_region_enter function call should be ok, because the ISR of an interrupt happening just before sd_nvic_critical_region_enter would be anyway invoked. If this ISR(*) triggers a FreeRTOS task, the scheduler would set that task to Ready.

Now the sd_nvic_critical_region_enter is called.

After this, a masked application interrupt sets the event flag but the ISR is not executed.

After sd_nvic_critical_region_enter, the function eTaskConfirmSleepModeStatus is called, which will abort the sleep process if a task or a task switch is pending (see served ISR above(*) ) - so here I see no problems.

If an interrupt happens after eTaskConfirmSleepModeStatus, it will set the event flag and the next WFE will be skipped - here I see no problem.

If an interrupt occurs after WFE, the normal wake up prcedure will happen and again here I see no problems.

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Wed, 09 Sep 2020 13:48:45 GMT

I see your point but

[quote user="dfer"]The Event flag is Always set because either a Task has been Yielded or an Interrupt has occured while the processor was not sleeping. The first time __WFE(); is executed will almost always go Forward without sleeping, causing another call to vPortSuppressTicksAndSleep form FreeRTOS.[/quote]

I see that the first one (Event set due to task yield) is not a problem, since the scheduler needs to be called before sleeping which is correct behavior that the sleep is aborted. You should not at this point try to clear that event that is the result of any state change of the task, this could cause deadlocks.

But I see that you have a point that if there is an interrupt happening inbetween the critical section, then the vPortSuppressTicksAndSleep code unnecessarily exits the sleep routine.

Wow, this is a good find. I am sorry that i missed to see the details of your previous reply. An interrupt could occur even while in critical section setting the event flag, so I am not sure that just clearing the event before entering critical section helps that much??

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Wed, 09 Sep 2020 12:15:37 GMT

Yes as said it you set a debug port before going to sleep and then reset ti immediately after WFE you'll see that the function is always executed twice.

Back to your comment "Your original suggestion to have __SEV; __WFE before just entering the critical_section is unnecessary since an event/interrupt can happen just after that."

this isn't right, since I would do the SEV/WFE before sd_nvic_critical_region_enter and later I would call only WFE (not SEV) thus no interrupts/events would be lost. If an interrupt occurs after sd_nvic_critical_region_enter, it would set the event flag, thus preventing the processor to go to sleep at the next WFE

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Wed, 09 Sep 2020 11:59:26 GMT

You are right, that seems risky. But I think I am deviating a bit from the original discussion.

Your original suggestion to have __SEV; __WFE before just entering the critical_section is unnecessary since an event/interrupt can happen just after that.

Do you have any benchmark results that can show that the current sleep implementation makes it execute twice before actually going to sleep?

If that is really happening, this discussion would be very serious. Initial tests i did does not show what you wrote. But i have not tested extensively.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Wed, 09 Sep 2020 09:55:04 GMT

No I didn't mean that. I meant between sd_nvic_critical_region_enter and __SEV()

In my opinion this Interrupt would be "lost". Yes, the pending bit would stay set, but the Idle Task wouldn't be woken up after the second __WFE because the Event flag is cleared.

I don't think that the Event flag would be set again if the Interrupt is still pending, I think it is a one shot Operation (set Interrupt pending -> set Event flag, but only once).

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Wed, 09 Sep 2020 09:23:33 GMT

I would recommend you to read this thread.

[quote user="dfer"] so a possible interrupt could have happened in between and we would clear the related event flag before going to sleep.[/quote]

The FreeRTOS port of Nordic enables SEVONPEND, so If the interrupt happens between the SEV and WFE, then you are right that the event is cleared, but the pend bit is set after one more clock cycle, so that should be ok as far as i can see.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Fri, 04 Sep 2020 11:10:33 GMT

I am not really sure but I see a danger that, if i do as you suggest, an event could be lost.

The sequence disables the application interrupts (sd_nvic_critical_region_enter), then asks FreeRTOS if there is a task pending, and then sets the RTC up.

Only after this, the event flag would be cleared. But the interrupts are already disabled, so a possible interrupt could have happened in between and we would clear the related event flag before going to sleep.

This is the documentation I've found About WFE:

WFE
Wait For Event.
Syntax
WFE{cond}
where:
cond Is an optional condition code, see Conditional execution on page 3-18.
Operation
WFE is a hint instruction.
If the event register is 0, WFE suspends execution until one of the following events occurs:
• an exception, unless masked by the exception mask registers or the current priority level
• an exception enters the Pending state, if SEVONPEND in the System Control Register is set
• a Debug Entry request, if Debug is enabled
• an event signaled by a peripheral or another processor in a multiprocessor system using 
the SEV instruction.
If the event register is 1, WFE clears it to 0 and returns immediately.

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Fri, 04 Sep 2020 10:31:29 GMT

I think __SEV;__WFE;__WFE sequence is a safe and well tested sequence to make the chip go to sleep on the second __WFE. Ofcourse there is a time chance that a new event flag is set after the execution of __SEV and __WFE but that is something we need to live with.

I am not sure why introducing __SEV;__WFE in the place you suggest improves the possibility of clearing the event flag. There are many instructions from this point to the actual next WFE where there is a great possibility for a new event to enter and raise the event flag.

In this function can you test the performance by not using sd_app_evt_wait and using __SEV;__WFE;__WFE instead of that.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Fri, 04 Sep 2020 08:59:08 GMT

Or even better here:

    /* Make sure the SysTick reload value does not overflow the counter. */
    if ( xExpectedIdleTime > portNRF_RTC_MAXTICKS - configEXPECTED_IDLE_TIME_BEFORE_SLEEP )
    {
        xExpectedIdleTime = portNRF_RTC_MAXTICKS - configEXPECTED_IDLE_TIME_BEFORE_SLEEP;
    }

    __SEV(); __WFE();// reset the event flag, if an interrupt has occurred and has triggered a task it will be caught in eTaskConfirmSleepModeStatus

    /* Block all the interrupts globally */
#ifdef SOFTDEVICE_PRESENT
    do{
        uint8_t dummy = 0;
        uint32_t err_code = sd_nvic_critical_region_enter(&dummy);
        APP_ERROR_CHECK(err_code);
    }while (0);
#else
    __disable_irq();
#endif

    enterTime = nrf_rtc_counter_get(portNRF_RTC_REG);

    if ( eTaskConfirmSleepModeStatus() != eAbortSleep )
    {

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Fri, 04 Sep 2020 08:33:29 GMT

Hi Susheel

after several attempts it seems that the SPEEPONEXIT functionality is somehow prevented by the softdevice.

Everything gets stuck after a time and I cannot understand why.

I would have another suggestion that would prevent the vPortSuppressTicksAndSleep to always be executed twice before managing to go to sleep:

    /* Make sure the SysTick reload value does not overflow the counter. */
    if ( xExpectedIdleTime > portNRF_RTC_MAXTICKS - configEXPECTED_IDLE_TIME_BEFORE_SLEEP )
    {
        xExpectedIdleTime = portNRF_RTC_MAXTICKS - configEXPECTED_IDLE_TIME_BEFORE_SLEEP;
    }
    /* Block all the interrupts globally */
#ifdef SOFTDEVICE_PRESENT
    do{
        uint8_t dummy = 0;
        uint32_t err_code = sd_nvic_critical_region_enter(&dummy);
        APP_ERROR_CHECK(err_code);
    }while (0);
#else
    __disable_irq();
#endif

    __SEV(); __WFE();// reset the event flag, if an interrupt has occured and has triggered a task it will be cought in eTaskConfirmSleepModeStatus

    enterTime = nrf_rtc_counter_get(portNRF_RTC_REG);

    if ( eTaskConfirmSleepModeStatus() != eAbortSleep )
    {
        TickType_t xModifiableIdleTime;
        TickType_t wakeupTime = (enterTime + xExpectedIdleTime) & portNRF_RTC_MAXTICKS;

The __SEV(); __WFE(); sequence resets the Event flag. If it was set because an Interrupt has occured, and this Interrupt has triggered a FreeRTOS Task, the subsequent eTaskConfirmSleepModeStatus would detect this and Abort the Sleep sequence.

The Event flag is Always set because either a Task has been Yielded or an Interrupt has occured while the processor was not sleeping. The first time __WFE(); is executed will almost always go Forward without sleeping, causing another call to vPortSuppressTicksAndSleep form FreeRTOS.

What do you think about this? I've tested it quickly and it seems working.

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Thu, 03 Sep 2020 07:09:05 GMT

I am not sure Davide, it should work, it is an ARM feature and does not seem to be optional.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Wed, 02 Sep 2020 13:22:08 GMT

Hi Susheel do you have any idea why the SLEEPONEXIT functionality doesn't work?

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Mon, 31 Aug 2020 12:48:55 GMT

[quote user="dfer"]I forgot to mention that the tick interrupt will always reset the SLEEPONEXIT flag (a Task switch is Always necessary in tickless mode at this Point).[/quote]

This will be a good failsafe mechanism. I think it should work.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Mon, 31 Aug 2020 12:39:32 GMT

In my other system I have about 30 tasks.

I forgot to mention that the tick interrupt will always reset the SLEEPONEXIT flag (a Task switch is Always necessary in tickless mode at this Point).

I cannot imagine why it shouldn't work, the other System runs since months with this method….

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Mon, 31 Aug 2020 12:23:22 GMT

Hi Davide,

[quote user="dfer"][/quote]

Let's say I call xTaskGenericNotifyFromISR

The function delivers the flag pxHigherPriorityTaskWoken.

I then check this flag in my ISR and, if set, I reset the SLEEPONEXIT flag. This ensures that the Idle task is woken up in order to perform the book keeping you were talking about.

This sounds like a reasonable thing to do, if there are only two tasks in your ssytem (the one giving notification and the other receiving it). But if there are other tasks, and if there is a dependency (inter task) between them, then your idea might not work.

If only two tasks, then I think this will work.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Mon, 31 Aug 2020 12:06:53 GMT

My example is taken from generic code, but basically I reset SLEEPONEXIT every time I'm sure a Task switch has to be performed.

RE: Interrupts not waking FreeRTOS up in Tickless mode

dfer — Mon, 31 Aug 2020 12:00:44 GMT

Thank you Susheel

waking up the Idle task needs energy. If I could avoid it then I would be very happy.

I have another project with a Cortex-M4 where I've done the folllowing:

Let's say I call xTaskGenericNotifyFromISR

The function delivers the flag pxHigherPriorityTaskWoken.

I then check this flag in my ISR and, if set, I reset the SLEEPONEXIT flag. This ensures that the Idle task is woken up in order to perform the book keeping you were talking about.

If the pxHigherPriorityTaskWoken flag is not set, I let the SLEEPONEXIT flag set and the processor will go directly in Sleep after the ISR, thus saving useless energy, because the Idle Task would do just nothing.

This is very needed also because, if you Instrument the vPortSuppressTicksAndSleep, you will notice that it is executed always twice before it can go really in sleep mode. This is energy that I would like to save.

RE: Interrupts not waking FreeRTOS up in Tickless mode

Susheel Nuguru — Mon, 31 Aug 2020 11:47:04 GMT

Hi Davide,

The tickless idle sleep wakeup only processes to see if there any other pending interrupts to be processed. If there are and if they are lower in priority than the kernel itself, then idle task needs to do the book keeping.

Enabling SLEEPONEXIT would keep the state machine of the kernel stuck in the idle loop for ever and might cause asserts in the future. What is it you are trying to achieve exactly? why is the post processing of idle task wakeup seems to be very expensive in your usecase?