I need to achive low power feature in my system, software was developed based on FreeRTOS 10.0.1 version.
The problem I met was only a small piece of SRAM on my chip have the retention feature in low power mode. I would like to store necessary FreeRTOS info into this retened SRAM and then the chip can enter into low power mode. After wakeup, recover the FreeRTOS info from the retended SRAM.
I would like to check if FreeRTOS already support this kind feature?
If no, what necessary info I need to store before enter into sleep, can I manually copy these contents into the specifica SRAM area and recover these contents after wakeup?
Low Power modes like that are really intended to be used by an application that saves just a bit of major system state in the ram and then shuts down to low power mode, and when it wakes up it essentially reboots the program and restores that state to continue sort of where it left off. As such, there really isn’t any ‘FreeRTOS’ state that likely is needed to be preserved there. The sram is treated as a fast, cheap, high endurance somewhat non-volitile memory store, not really application ram.
If you really need for the program to resume from where it left off before going to sleep, you likely can’t use that deep of a low power mode, it really isn’t meant for that.
The other sort of program that can use that mode is one where really all of the system state can be stored in that retained sram, and the rest is only used for ‘scratch’ work that can be redone as needed after wakeup.
The tickless idle feature has pre and post sleep macros that enable you
to perform any application specific actions that may be necessary or
desirable. However this normally involves starting or stopping clocks
or peripherals rather than saving the entire state. If you want your
system to wake from a low power state and continue exactly as before the
low power state then you would have to save all used RAM - and it
doesn’t seem that you have enough retained RAM to do that. Most people
will just choose the lowest power state that maintains the RAM’s contents.
If your intention is not to continue as is the low power mode was never
entered but instead restart the system then it is not clear what
information you which to retain across low power entry and exit.
Thanks for your quick repsonse.
Let me clairify two methods you provide,
Just only storage application related contents into the small piece SRAM which has the retention function in low power mode. No need to store any FreeRTOS related contents into this SRAM. For this method, everything like fresh start after wakeup from low power. The system need to spend some time on the initialization, such as create all the tasks, timers, event groups, etc. Also all the hardware related driver need to init as well, such as Flash, PWM, GPIO, etc. I’m not sure how long it takes.
Store all system state of FreeRTOS into the retained SRAM, and copy to right parameters after wake up.
Please correct me if my clairification is wrong.
If I want to try 2nd method, could you point me out what exactly info in FreeRTOS I need to care and store to reatined SRAM before sleep. Does the FreeRTOS provide APIs that I can get these info directly.
The second method basically means you link the application to primarily use only the memory that is saved (you don’t ‘copy’ to it, you just use that as your ram). It is likely that you program doesn’t fit there so you can’t use that option. If you can use this option, then your boot up code needs to very early on check if it is a cold boot or a warm boot from low power, and if it can resume just reinitialize the hardware and then continue.
As far as the first method, generally most of the modes which only retain a little bit of the ram don’t retain peripheral configuration through that low power mode, so you would need to do that anyway. In this case you can probably get all the way to the beginning of main before you need to check if this is a warm boot or a cold boot (and cold boot would effectively initialize that save memory instead of retaining it from the previous session).
For example, my chip only has 1KB SRAM has the retention function in low power, but I set the HEAPSIZE to 10KB. I know it’s not reality to store all the task stack info/heap info to 1KB SRAM. The only thing I can, pick the most necessary info that can I help me to recoever the RTOS system to the state before enter low power mode, such TCB, CPU registers, etc.
So far I don’t know what necessary for FreeRTOS can help me to recover state before enter low power mode.
If the chip has 1KB of retained SRAM, and the application uses more than 1KB of SRAM to run (which yours does), then basically you can’t just ‘recover state’ and continue, you just can’t save enough state. YOU will need to design your application to have less than 1 KB of ‘application state’ that is retained between deep sleeps, that combined with whatever other ‘fully persistant’ state that keep somewhere in flash/eerom lets you resume between sleeping to give you the experiance you are looking for.
Waking up from this type of sleep is basically very similar to a cold rebooting of the processor, only a little bit of memory was saved, which can be used to keep track of some application state that might be changed too often to make sense to save it to flash.
Generally, this sort of low power state is connected with an appearance of a sleep to the user, and virtually any form of ‘display’ (except maybe E-Paper) will consume enough power that you might as well leave the processor in a higher power state that keeps all of the SRAM alive allowing a simple resume at the code level. This means that if you can reboot in a few tenths of a second, it is probably acceptable.
Hi Richard D & Richard B,
Thanks for your previous answer and help.
I will follow your suggestion, let the system warm start in main() funcction after wakeup from sleep. For the 1KB SRAM retention in sleep mode, I just store some important application level parameters in this SRAM.
But one problem still confuse me.
For tickless mode in FreeRTOS, the OS will calcute the sleep time automatically based on the event in OS, such as RTOS timer event. For example, the latest event for RTOS is a 5s timer. I will set the hardware sleep timer in 5s and then the system go to sleep.
After wakeup, the sw start from main() for warm start. So the question is how to let the RTOS know the wakeup is caused by a 5s OS timer, and need to process the callback of this time since these is no RTOS info stored before sleep.
First comment, I am not so sure this level of sleep is really right if you are going to be waking up after 5 seconds, and it makes a difference if the wake up was the 5 second timer or something else. It really sounds like you really want a sleep mode that keeps full system state. Just wanting to go tickless idle likely isn’t enough to be able to use this type of sleep.
As to how to handle the question, mosgt processors on wake up can interogate the way they were woken up and the source of the signal. Your code, early enough in the startup to get this data (before other initializations overwrite it) needs to records the cause, and then use that to affect what gets started at the beginning of the running under FreeRTOS.