ciaranmaca wrote on Wednesday, November 06, 2013:
Thanks for the reply Dave. Yes I do have stack overflow check on, nevertheless, it is worth adjusting the minimal stack size to see. But that might not solve my problem…
Why not use build in low power? As far as I see there are two very good low power strategies for cortex:
-
Use a timer other than systick for the rtos tick. This allows the idle hook to drop into a very low power mode where peripheral clocks and system clocks (including the one that drives Systick) are off. (I am using this strategy with a twist - more below)
-
Tickless Idle. This is the ‘icing on the cake’. I don’t think I need to go this far. I can live with the short wakeup on every sys tick given the short time it takes the sheduler to determine that no tasks are on the ready list and therefore that it will go back to sleep.
The Twist. My app does UART and SPI comms. The driver code for these uses rtos events to determine end of transmission, and for uart, end of message for rcv. During these rtos calls the sheduler can and will drop into IDLE and enter the very low power mode. But this kills my peripherals. The scheme to get around this was to wrap my “send/rcv” primitives in a “don’t do deep sleep” flag system. Now when the idle runs if it sees the flag set, it will drop into a moderately low power mode which leaves the peripherals enabled but which stops the core.
Lovely - except that it doesn’t work :-(. Because IDLE hook cannot block I think there is no way of forcing a safe mutual exclusion so that there cannot be an erroneous drop into very low power. Even if the IDLE hook checks a flag or peeks at a counting semaphore and determines that very low power can be entered, it (that is, the idle task) might now be interrupted by the tick, the scheduler might run allowing a task which is going to communicate to run, and when idle next runs it will drop the system into the very low power mode. Bang. Comms are now compromised.
I cannot think of any way around this at the moment. A plan B is to not use very low power at all, but my current budget is not going to make that attractive. Second is to do what I once did before - implement a low power manager which the tasks check in with and which can then safely put the uP into very low power mode.
But implementing my own power manager is less efficient, since it operates outside the RTOS. Indeed, when you think about it, the RTOS, which manages tasks, is precisely where this management belongs. But at the moment, I’m a bit stuck.