slitherio wrote on Wednesday, December 07, 2016:
Thanks for the reply.
It is little more complicated with the BLE stack. I should have explained it before. Now I see what confuses you both.
The BLE stack is a completely different binary running first at system start up. At system start up it is IDLE and it gives CPU to the RTOS application which is another binary running on top of BLE. We have interrupt forwarding mechanism for the interrupts that BLE stack does not consume which are forwarded to the application vector table. The communication between the RTOS and the BLE happens using SVC and when RTOS starts one of RTOS threads initializes the BLE stack (and this stack which runs out of the scope of the RTOS as this is a seperate binary listening and consuming a range of SVC numbers).
So when i said that the BLE activity can mask interrupts for a long time, it means that this will happen completely outside RTOS scope. For example, one thread in RTOS triggers a SVC call that immediately transfers control to the BLE stack (not RTOS thread) and that sometimes could takes many milliseconds before it gives control back to the RTOS thread. The RTOS tick counter, RTC , is always ticking no matter what is running. So now even though the hardware tick is ticking, RTOS did not get CPU at all for doing its tick housekeeping, I understand that any RTOS does not like CPU being hijacked and in this scenario BLE stack is stealing the CPU time from it abruptly, which is OK and it is working fine because all the hardware timers are still ticking for the RTOS and* I just needed a way to tell the RTOS that you were not allowed your housekeeping for a while and here is the diff in the ticks and go do your housekeeping.*
Now, back to your explanation.
but presumably the BLE task will run at any time, and most of the time it runs there will be other tasks that are not Blocked
The BLE activity that steals CPU from the RTOS is not an RTOS task, so when Tickless IDLE is triggered, then all other tasks apart from IDLE are blocked. This condition is still met on our port.
***and that the system will exit tickless mode before or at the time it is known that a task needs to leave the blocked state. ***
When the system sleeps using tickless idle, it will never exceed the time to wakeup than what the RTOS has expected, because we configure a wakeup interrupt with that expected time. In many cases it wakes even earlier, because if we are triggering ticksleep sleep, that means that all the threads in the RTOS (apart from IDLETask) are in blocked state and the BLE stack is in IDLE state.So this condition is also met.
I have experimented removing the compile flag fencing the implementation of xTaskIncrementTick() and used it in the system as mentioned in the question to see if i trigger any assert. All the systems have been up and running for more than 12 hours without any assert. And the timers have improved efficiency when i use vTaskStepTick to compensate the lost ticks.