Hi,
I've got a question: is it possible to use Standby Mode in Idle Hook or in Tickless Idle Mode? In standby mode SRAM and register contents are lost except for registers in the Backup domain. But in the Backup registers one can store only 84 bytes of user application. I think it is too litle - because I will lose system stack, tasks stack, system variables etc. Am I right?

Correct - you cannot enter a sleep mode that loses the CPU context, or the saved context for any of the tasks.

Regards.

ok, thans.
But how can I find a place in memory where OS stores its variables, tasks stacks etc? Because I think it is possible to use a Flash Memory (emulating EEPROM) to copy this data and restore it after wakeup.

You could use the linker script to force the data into a known memory section, then save that section. That is similar to how the FreeRTOS-MPU port works (it uses the PRIVILEGED_DATA and PRIVILEGED_FUNCTION macros to force function and variables into a linker section). Alternatively you would have to add some functions into the kernel code that gave you access to the addresses of file private data.

You would have to save all the file private data (static variables) from source/portable/tasks.c, and the stack of every task. The stacks will come from the heap, and where the heap memory comes from depends on if you are using heap_1, heap_2, heap_3 or heap_4.c (or your own memory manager).

Is there much to be gained between using the second lowest low power mode (which keeps the registers and RAM powered) and the lowest (which looses the register and RAM data)?

Is it possible just to store a little state information in flash, then just restart the system completely when the MCU comes out of sleep mode. When you boot the system you can read the state information out of flash to inform your application of what it was doing when it was shut down.

Regards.

A mode which loses most of memory and keeps just a bit of info is intended to be used in a mode where the processor in effect "reboots" on wake up, and the application uses the saved info to restart from where it was instead of at the beginning again by saving the APPLICATION state. Each of your tasks (that need it) would need to be allocated space in the Non-volatile memory to save its state, and would restart base on it. This would NOT be a full stack dump, but the few key parameters needed to restart from the last key checkpoint.

Normally it takes long enough to "restart" the processor, and would require too much state to have this happen just because you are in idle. Normally it is done when all the tasks have completed their major work (so they don't need to save much state to resume), and you are going to be waiting for some significant event that might not happen for awhile, when the processor will drop into standby.

Normally a simple low power mode (which is easier to recover from) is used in the idle hooks.

Many thanks for exhaustive answer. In the lowest power mode typical current consumption is around 10x lower.But I have to consider all pros and cons.
Regards

You need to be carefulll not to get "milliwatt" wise but "watt" foolish, these ultra-low=power states do consume a lot less power than normal operation, but due to what is needed to recover from them, they might have a moderate wake-up cost in terms of power. If you are going to be waking up on the next timer tick, which you know will be happening soon, anyway, it can well be a net LOSS of power to go into a deep power-save mode.

I typically have the idle loop go into a very mild low-power mode, one which requires little (if any) operations to wake up from. When the application detects that it doesn't have anything to do now, and is waiting for a user command, it may go into a deeper sleep. The ultra low power modes like this are for when your device detects that it isn't being used at the moment, and can go totally asleep, waiting for something to wake it up to be used again.

Yes, that is why the tickles idle mode allows you to configure how long the expected sleep time should be before it considers going to sleep. It also provides pre and post sleep hooks to allow application specific processing - this is how the SAM4L and RX100 reference ports set their chip specific sleep mode.

Regards.

Thanks again.
I just asked my question thinking about tickless idle mode.
Regards

hi again,
I've go some questions regarding using FreeRTOS and deep sleep mode. So, I've got a FreeRTOS with tickless idle mode, I create two tasks, both blink led, with freq 0,5Hz and 1Hz. When idle task is executed, MCU goes into standby mode and then it loses content of its registers and RAM. As you said, after wakeup it's like rebooting, so I create tasks and start scheduler again. And my question is - when I restore (and update) number of ticks after wakeup - does the scheduler unblock (or "unsuspend") my tasks in correct time? What does scheduler need to correct work? only time (number of ticks) and state of tasks? I'm sorry in advance, maybe my questions are naive, but I tried to find such information and I didn't get it.

I don't think FreeRTOS has any provisions built into it for "restoring" your state after a deep sleep (the problem is that FreeRTOS doesn't know enough about your tasks to know what to remember about them. Thus when you recreate your task, they are starting fresh. Your tasks need to look at the information saved in the non-volatile memory to restart themselves in their previous state (and somehow get that data saved before going to sleep).

As I said, deep sleep is NOT something to casually use to save power, but a deliberate decision in the code to shut down to be restored at a latter point, with only a need to save limited information across the shutdown.

Ok, thanks