For my design, I have my timer interrupt code working the way that I expect (running 100% of the time in EM0 without the DC-DC converter). For my next task, I wanted to get the power system out of bypass mode, and start using the DC-DC converter to reduce my power. So I downloaded AN0948, and started reading. It appears that this module is more complex that I had anticipated. Certainly more complex that turning it on and setting a few bits.
As I continued to read, it appears as if I may need to reprogram the DC-DC converter when I switch between EM0, and EMU2 due to the extreme load change (mA to uA to mA). Is this standard procedure ? Is it necessary ? How many of the DC-DC configuration parameters only have to be done once, and how many (if any) needs to be changed when transitioning between energy modes ?
The app note recommended using the EMLIB functions, so I looked at the functions inside "em_emu.c" used for programming and manipulating the DC-DC, and entering/exiting sleep modes
I know there is a lot of stuff in here to make it a more generic library to support different parts, but even with that aside, it looks like a lot of code ! Where machine cycles is power, every machine cycle matters.
Now for a more specific question. One of the functions in this lib is called "emuRestore". According to the description, it is used to restore the oscillators and core clock after having been in EM2 or EM3. So lets say that I wake from EM2 mode by a timer interrupt, does emuRestore have to be run at the beginning of the timer interrupt ? This seem counter-intuitive to me since the core clock has to already be running before you get to the ISR.
The function emuRestore is called in function EMU_EnterEM2. I assume that EMU_EnterEM2 would typically be called from outside an ISR (say main). Is emuRetore called after return from EM2 from main, then the ISR would be executed after emuRestore was run ?
I apologize for so many questions, but I can't afford to blindly run functions from a library without knowing the impact on how many machine cycles that it will cost me.
You're right that the DC-DC converter is a complex piece of hardware with a very thin abstraction layer that exposes a lot of the configuration to software. On the EFM32xG1 devices, there are also a few erratas with the hardware state machine of the DC-DC converter. This means that software needs to take more run-time control of the configuration to ensure safe operation. Most of these erratas are fixed on EFM32xG12, though. See the errata document for your device for details about the errata.
As for the "emuRestore" function (refactored and renamed "emState" in latest SDK release): When the device enters EM2, the high-frequency oscillators are turned off to save power. When you exit EM2, the device always comes back up using the HFRCO. The reason for this, is that the HFRCO starts up in a few microseconds, while HFXOs may take much longer (10s to 100s of us) to start. If the "bool restore" parameter to EMU_EnterEM2 is set to "true", the previous oscillator configuration will be restored (i.e. starting up HFXO and switching to it, and for EM3 also re-starting LF oscillators) before returning from the function. Though, as you note, this means that your ISRs will execute using the HFRCO, since the HFXO isn't restored until code execution returns to the EMU_EnterEM2 function.
If you desire your ISRs to also wait for the oscillator configuration to be restored, you can set PRIMASK before entering EM2. If PRIMASK is set, you will wake up from the energy mode just like normal, but the execution of the ISR will be delayed until PRIMASK is cleared. Instead, the processor continues executing code in thread mode. Example:
// <-- ISR is executed here, rather than immediately upon wakeup inside EMU_EnterEM2()
See the software documentation for em_emu for more information about what the software does upon energy mode entry and exit: http://devtools.silabs.com/dl/documentation/doxygen/5.1.0/efm32pg1/html/group__EMU.html#gacadc56c5e2a8fb2890edd139b694b25b
I finally got DC-DC initialization code running. I measured the time from the start of the initialization until completion at 60uS with a core clock of 32MHZ ! This "seems" like an extraordinarily long time to me. I think that I can take this on power up, but once I'm running, I can't take 60uS to change DC-DC configuration. So I hope that I won't have to.
I hope that entry and exit between the EM0 and EM2 power modes doesn't take this long.