Tickless implementation

Kernel
1

Hello,

I have a topic which I find difficult to understand.
I am using the Tickless option for the low power management on a cortex m33. I dont know how to handle the critical section that the vPortSuppressTicksAndSleep needs. Is this critical section really needed? what if important interrupts are coming during this idle period’s critical section and they are not served at the correct time? how could I avoid getting into timing problems, should I remove the critical section in order to react to the interrupts?

thank you for possible answers,
Virginia

2

vPortSuppressTicksAndSleep() is part of the kernel code, so should not be edited. I’m not sure which critical section you refer to - but if it is part of the tickless implementation I’m pretty sure it will be essential. Can you link to the code that is concerning you and elaborate on the scenario you think will be a problem?

3

Are you talking about this critical section - FreeRTOS-Kernel/portable/GCC/ARM_CM33/non_secure/port.c at main · FreeRTOS/FreeRTOS-Kernel · GitHub? Are you worried that you may miss an interrupt when your device is in sleep mode? If yes, any interrupt fired during sleep will bring the device out of sleep mode.

4

Hello! Yes, I am reffering to the critical section, respectivelly the disabling of the global interrupts.
/* Enter a critical section but don’t use the taskENTER_CRITICAL()
* method as that will mask interrupts that should exit sleep mode. */
__asm volatile ( “cpsid i” ::: “memory” );
__asm volatile ( “dsb” );
__asm volatile ( “isb” ); This code isnt’t it supposed to disable the interrupts?
Particularrly, I am using a user defined function for vPortSuppressTicksAndSleep(), not the one from the port.c But it includes entering a critical section before going to low power mode, using __disable_irq();
So you mean the mcu will be waken up by interrupts even if calling __disable_irq();?

Thank you!

5

I am talking about the disabling of the interrupts before entering in low power mode in the vPortSuppressTicksAndSleep function.

6

After you execute wfi instruction.

7

in my vPortSuppressTicksAndSleep() implementation I dont call the wfi instruction, I use a deep sleep mode.

8

My understanding is that , if in the vPortSuppressTicksAndSleep I have the function call of __disable_irq() -and then I call for the MCU to enter in the sleep mode for the xExpectedIdleTime, and after exiting the sleep I call __enable_irq(), there is the rick to loose some interrupts that can come during that period of time. What does it happen between __disable_irq() and __enable_irq()?

9

You will need to look at the description of that deeper sleep mode to see what wakes it up. If that interrupt will do it, then it will wake up. If that interrupt will not wake the processor up, and you need to service that interrupt, you can’t use that deeper sleep mode.

Normally, the use of those deeper sleep mode needs application level decision logic that you are confident that nothing needs to be done for awhile, and that you have an appropriate wake-up source, before going to sleep.

Note also, that going into and out of these deep sleep modes takes some time, and actually can cost power, so if you won’t be in it long enough, do the opposite of being a power savings.

10

yes, I am aware of what events are supported by the sleep mode chosen, my concern is strictly related to the call to __disable_irq() - as my understanding is that no matter which power mode I enter after calling it, the possible ISRs wont wake the system up until __enable_irq is called. is this right?

11

Read your processor documentation!

Note, the reason for using the cpsid instruction instead of calling __disable_irq is that the former leaves the interrupts unmasked, just disabled, while on the Arm Cortex ports, __disable_irq is really a mask interrupts operation, and masked interrupt do not wake the processor from wfi.

So, if masking the interrupt is enough to not let it wake up, you can’t use a function that "disables’ the interrupts by masking them.

12

Not quite. The ISR won’t execute until __enable_irq is called. The processor wakes up when the interrupt occurs, even though interrupts are disabled.

And for clarity, __disable_irq() and “cpsid i” are the same. The masking method to avoid here is taskENTER_CRITICAL() because it masks interrupts via BASEPRI, which would prevent the corresponding interrupts from waking the processor.

1 Like
13

Thanks a lot for the explanation. This is what I felt is happening from the behavior, but I didnt find the right documentation to get this same idea about how __disable_irq() is working.

14

yes, actually i did not find very clear info on this. Seems that cpsid instruction is actually using the PRIMASK register,thus it permits the mcu to wake up, but just not execute the interrupt unsless they are enabled.