Hi Richard,
Thanks for the answer.
I am using SW timers as well along with the tickless idle mode,
therefore is it safe to assume that |eTaskConfirmSleepModeStatus()|
always returns either |eAbortSleep| or |eStandardSleep| ?
I don’t think the behaviour or eTaskConfirmSleepModeStatus() will change
if you have software timers – but eStandardSleep is not one of the
values it returns – is this just a mistype or did you get the code from
somewhere other than us?
I am using the official FreeRTOS port and this is what is in the
task.h
file.
~~~
/* Possible return values for eTaskConfirmSleepModeStatus().
/
typedef enum
{
eAbortSleep = 0, / A task has been made ready or a context switch pended since portSUPPORESS
TICKSAND_SLEEP() was called – abort entering a sleep mode. */
eStandardSleep, /* Enter a sleep mode that will not last any longer than the expected idle time. */
eNoTasksWaitingTimeout /* No tasks are waiting for a timeout so it is safe to enter a sleep mode that can only be exited by an external interrupt. */
} eSleepModeStatus;
~~~
If the behaviour of what
eTaskConfirmSleepModeStatus()
returns does not change depending on the usage of software timers I think we’re fine.
If interrupts were enabled before going to sleep you would get into a
race condition as an interrupt may occur that unblocks a task, then you
would enter sleep mode when you shouldn’t. The hardware is designed to
avoid this – hence when you sleep with interrupts disabled an interrupt
will still bring the MCU out of sleep mode BUT the interrupt will not
actually execute until you enable interrupts again.
Thanks for the explanation, Richard. I now understand the rationale behind the chunk of code there. I think I have found the relevant information in the chip datasheet as well. It’s as follows.
Some embedded systems might have to execute system restore tasks after the processor wakes up, and before it executes an interrupt handler. To achieve this set the PRIMASK bit to 1 and the FAULTMASK bit to 0. If an interrupt arrives that is enabled and has a higher priority than current exception priority, the processor wakes up but does not execute the interrupt handler until the processor sets PRIMASK to zero. For more information about PRIMASK and FAULTMASK see Exception mask registers on page 22.
So, I assume still this would take
BASEPRI
value into consideration and would execute instructions untile the interrupts are re-enabled and would execute the ISR afterwards. So, ideally the above code (
vPortSuppressTicksAndSleep
) should work without enabling the interrupts then.
Just another question specially regarding the use of low power timer(LPTIM) for tickless idle mode with deep sleeping. I know this is going to be a bit chip specific rather than RTOS related, but I would like to hear from anyone with similar experience.
The current STM32 datasheet for LPTIM mentions that* reading counter register is not reliable and it should be read consecutively until they become identical to assert that it is a valid counter read*. I’m using LPTIM for my time base in tickless idle implementation and actually relying on the value of counter register in time adjustment calculation.
As of my current observation, the entire implementation is quite unreliable and I notice a slippage in time when using LPTIM with RTOS tickless mode to transition to STOP2.
Does anyone have success using LPTIM with tickless idle, or the above extract from datasheet is sufficient to suggest that LPTIM
can not be used as a time base with tickless idle mode.
Any way to isolate the issues, I’m currently in the process of using tickless idle with a GP timer (but of course then I have another issue of not being able to use STOP modes and have to go to SLEEP mode instead, which further raises concerns about the power budget).
I highly appreciate your thoughts on this.
Thank you in advane.