I wrote a test program that puts the Apollo3 A1 processor into a pair of alternating sleep configurations. Before going to sleep on the first sleep cycle, the processor gets configured in one fashion. When it wakes from sleep, it reconfigures for the second sleep cycle and goes back to sleep. This makes it easy to get A/B test results from a single run knowing exactly what is different between test phase A and test phase B. Each phase lasts for 8 seconds in order to let the current meter reading settle down. I discovered that if you are using a hardware debugger to program the flash, you must disconnect the debugger and then power-cycle the board being tested before recording any power measurements. Without the power cycle, the debug unit in the processor will remain active and use significant amounts of power, distorting the results.
Things I learned:
The 32KHz crystal oscillator is really power efficient: it make almost no difference between using the crystal oscillator or the lower powered (but significantly less accurate) 1 KHz RC oscillator
leaving the flash powered during sleep is a big power waster
powering down unused SRAM saves power, but not really a ton. If you need it, use it!
leaving the cache powered during sleep costs almost nothing but should improve wakeup performance if your system needs it
Most importantly: the rev A1 processor bug that requires PDM to be enabled at all times is a significant power waster. See viewtopic.php?f=171&t=51061
I have attached a somewhat readable pic of the results. The tests come in phase1/phase2 pairs where the specific thing being tested in the two phases is highlighted in green. For example, in the very first test the processor has an identical configuration in both test phases, but phase 1 sleeps in deep sleep, and phase 2 sleeps in “normal” sleep. The two test pairs highlighted in yellow are identical, except for the configuration of the STimer to use the 32KHz crystal or the 1KHz RC oscillator for both tests. It was easier to do that than switch oscillator speeds within a single test pair.
Obviously, all of these current measurement numbers represent “typical” values for a single system and your mileage may vary. The goal was to identify the typical costs of running various parts of the silicon, and to see how low things could go.
Test conditions:
Sparkfun blackboard with Apollo3 rev A1 processor
VCC: 3.294V
MEAS trace cut
Microphone power trace cut
Power fed from external supply through current meter into processor side of MEAS jumper