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
Very useful information. Thanks.
I wrote a test program to look at the relative power consumption between the various processor clock rates: 24 MHz, 48 MHz, and 96 MHz Burst Mode. The software being executed was identical in all three cases and was based on the Prime Number calculation code from the Ambiq Suite “third party” software directory. I had the compiler optimizer off, so there were a bunch of RAM accesses being performed, but the entire program would be executing from cache. The benchmark itself is kind of immaterial since the point is to look at the relative power consumption at various clock speeds. To that end, the program would calculate the primes while running at 24 MHz, then switch to 48 MHz and recalculate them, then to 96 MHz Burst Mode and recalculate them, then disable Burst Mode and go back to the 24 MHz clock and repeat the sequence indefinitely.
For the first iteration of the test:
- 24 MHz: 237 uA- 48 MHz: 444 uA- 96 MHz: 2120 uA
Since the supply current at 24 MHz is more than half the current at 48 MHz, it indicates that there must be certain fixed energy costs to running the CPU that don’t really depend on how fast it is running. The net result is that running the processor more slowly over an identical set of instructions is actually slightly less energy efficient even though the current draw is lower. In addition, running the processor in Burst Mode is significantly less energy efficient than running at 48 MHz: it takes nearly 5 times the current to run the processor only twice as fast.
So there you have it: 48 MHz operation is the most energy efficient, at least in this case. But I suspect that this will represent a pretty general outcome.
Finally, there was one other interesting thing that come out of the testing. On all subsequent iterations of the test, the 24 MHz number is consistently higher than the first time through:
- 24 MHz: 256 uA- 48 MHz: 444 uA- 96 MHz: 2120 uA
This result is extremely repeatable. Power cycling the chip indicates a lower 24 MHz current on the first test iteration than all subsequent 24 MHz test iterations. Also, if I disable the burst mode portion of the test and only cycle through the 24 and 48 MHz tests, the 24 MHz power never changes. That would seem to be an indication that either when enabling or disabling burst mode, some part of the chip is being left in a slightly different mode that takes a bit more power during subsequent 24 MHz operation. If a system only switches between 24 and 48, or between 48 and 96, it won’t matter. But if you really want to use all three processor clock rates in the same system, you might want to figure that out or else 24 MHz operation will cost you a bit more than it should.
