Dec 16, 2013 Cortex M0+ tickless supportPosted by nurichard on December 16, 2013Hello, I am looking to use FreeRTOS’s tickless mode on a Cortex-M0+ core in the Freescale Kinetis KL series microcontroller. As far as I can tell, the latest version of FreeRTOS (v7.6.0) does not officially support tickless for a Cortex M0 (or M0+). There is a.
NOTE:This is a read only archive of threads posted to the FreeRTOS support forum. Use these archive pages to search previous posts. New forum support threads can be started at the. FreeRTOS Support ArchiveThe can be used for active support both from Amazon Web Services and the community. In return for using our software for free, we request you play fair and do your bit to help others! Sign up for an account and receive notifications of new support topics then help where you can.This is a read only archive of threads posted to the FreeRTOS support forum.
Use these archive pages to search previous posts. New forum support threads can be started at the. 115200 should be slow enough that critical sections used in FreeRTOS are short enough not to lose interrupts, and Suspending/Resuming the Scheduler won’t block them.The one thought I have is that you are putting the device into too low of a low power mode that actually turns off the devices, and/or takes too long to wake up from when going into tickless idle.There is also a possibility that there is some sort of hardware bug that is causing an issue, but my first guess is that your definition of ‘low powr idle’ is too low. I’m not going into sleep mode, I’ve commented the code out and just have:vTaskSuspendAll;xTaskResumeAll;Added in to replace as it’s these lines of code causing the issue, these lines are code are executed before and after (one of each) sleep mode (or the decision on when to sleep) is made.In normal (non tickless) mode of FreeRTOS these calls are not here and it works perfectly as you would expect, but the moment these calls are introduced into the equation I start losing serial interrupts. I’m not sure I fully understand the original question. Does this haveanything to do with tickless mode, or are you just noting that callingxTaskResumeAll causes interrupts to be missed?vTaskSuspendAll would have little if any effect on interrupts – henceI’m ignoring that.xTaskResumeAll does have a critical section but that would do littleunder normal circumstances.Are you generating an interrupt on each 115200 characters per second?If so, can you minimise the overhead using a DMA or FIFO? Hence you can’t use the pre and post sleep macros to abort entering lowpower mode as they are in the section that executes with the schedulersuspended.
The tickless entry/exit actually has to be done with thescheduler suspended to allow the kernel to know what the situation is onexiting sleep mode. Likewise to give the pre/post sleep macros a knownexecution state.First, if the UART interrupt can be implemented without using anyFreeRTOS API calls then you can set its priority aboveconfigMAX SYSCALLINTERRUPTPRIORIY (which on a Cortex-M means a lownumeric priority value, 0 being the highest priority).Other than that it is a curious situation. My thought process was thatsuspending the scheduler is very fast and doesn’t have any criticalsections. Resuming the scheduler does however have a critical section –and that if all your idle task is doing is calling xTaskResumeAll overand over again very rapidly then it will spend a good proportion of itstime in that function – however likewise as it is being called rapidlythe amount of time spent inside any single call of the function shouldbe extremely short. I’m afraid I don’t really have any other thoughtsat this point. Hi Richard,at this point with tasks.c as it stands the behavior tickless mode is (as far as i can tell) broken (i understand we may have opposing views on this! Im trying to be as subjective asni can) the critical section there kills interrupts which it shouldnt,any chance of implementing the “fix” as i have described above into the freertos code, by default the default defined value could be 1 so that it operates as it did, but allows tickless to be enabled with no extra overhead with the critical section.
Although it doesnt fix it with regards to lost interrupts whrn tickless mode is allowed, it does fix it when sleep is not allowed.i was very surprised by this behaviour, especially when i implemented it as suggested and told it not to allow sleep, i didnt expect to see lost interrupts.