This might be a bit obscure and I might be jumping at shadows here.
I am running FreeRTOS 7.4.0 on an EFM32LGxxx (Cortex-M3 core). The OS ticks are implemented using the on-chip RTC and the system has my own tickless sleep mode implementation.
I have an ISR which is active during the tickless sleep, and this has a call to xTimerStartFromISR(). I am passing a valid memory address in for the second parameter - this seems to be essential to make sure that xQueueSendToBackFromISR() is called instead of xQueueSendToBack().
When entering tickless sleep, just before the call to portSUPPRESSTICKSAND_SLEEP() I see that vTaskSuspendAll() is called, and xTaskResumeAll() is called afterwards (from tasks.c). Looking at the documentation for vTaskSuspendAll(): "API functions that have the potential to cause a context switch (for example, vTaskDelayUntil(), xQueueSend(), etc.) must not be called while the scheduler is suspended."
Based on this, is it safe to call the xQueueSendToBackFromISR() / xTimerStartFromISR() functions? I gather that they will not cause a context switch, but I am just hoping to clarify this to make sure there are no problems!
this seems to be essential
Yes - you have to pass in a valid value in the pointer.
Based on this, is it safe to call the xQueueSendToBackFromISR() / xTimerStartFromISR()
I think this is fine. When the scheduler is suspended you cannot call a function from non-interrupt code that can cause the calling task to block. The reason being that a context switch cannot occur when the scheduler is suspended, so the task cannot block, and the program logic is therefore messed up. In your case you are calling the function from an ISR, so you don't have the scenario just described - you cannot block in an ISR anyway.
Great, thanks very much for your quick answer Richard!
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.