I’m experimenting with tickless mode on IAR/MSP430X port. I configured FreeRTOS to use that mode and provided my vApplicationSleep implementation. Everything seem to work but I’ve noticed that tasks actions unblocked by ISRs (which always yield too) happening during tickless sleep are delayed. Looking at the FreeRTOS code, I’d say the cause is the following: the scheduler is suspended right before sleeping, so any yield is held pending during tickless sleep, unless the ISR explicitly clears LPM flags on the stacked status register before returning, which isn’t needed in “ticked” sleep. Is this an intended behavior? Best Regards, Peppe

Sorry not to reply before – I only noticed your post while taking the archive backup. There is no official tickless example on the MSP430X, so I can only comment on the intended behaviour of the generic parts of the code. The scheduler is suspended before the tickless sleep to ensure there are no race conditions when the sleep exits, and to ensure any power specific CPU context can be restored before tasks start to execute again. The sleep mode chosen should not prevent interrupts from executing, and the interrupt should bring the CPU out of its sleep mode. The interrupt can request a context switch, but the context switch will not happen because the scheduler is suspended. When the CPU starts running again (after exiting low power mode) it will do whatever is necessary to correct the tick count, then unsuspend the scheduler. At that point any pending context switches will occur. Regards.

Thank you for your prompt answer (and for FreeRTOS of course). Therefore I will modify the existing application code, making sure that any give/send action from ISR and explicit yield is always followed by the exit from low power mode (which would cause an unnecessary cycle of the idle task in normal ‘ticked’ mode). Regards, Peppe