Hey guys,
I haven’t been able to find any information regarding the current draws for the various Redboard Artemis boards (i.e. ATP, Nano, etc.). Would you be able to point me towards where I might be able to find what the operating and quiescent draws are for the three board variations?
Cheers,
Adam
Hi Adam,
Your results are going to vary depending on what you have the processor doing and how you are powering it. I am going to ask around to see if we performed more thorough tests but in a quick test using a variable power supply at my desk, these are the results I have from powering both the RedBoard and ATP versions out of the box (running Blink) with 7V into the barrel jack connector:
The current draw when powering via USB will be lower than these results since you are bypassing the variable regulator for the barrel jack input.
The Nano is a bit different since it does not use the LM117 regulator and also has the battery charging circuit included. In my testing with 5V applied to VIN the Nano was consuming ~6-7mA and ~4mA with 3.3V provided directly to the 3.3V pin (again while running Blink).
Finally, if you just want to measure the draw of the Artemis module on its own, you can sever the MEAS jumper on either the RedBoard or ATP versions (the Nano does not have this jumper) and then solder wire or headers to the pins next to that jumper to isolate power to the Artemis module and measure with an ammeter/multimeter.
Hi Mark,
Thanks for your reply. I’ve since picked up Redboard Artemis Nano and have conducted some tests to determine the current draw under varying conditions. The tests involved uploading the Blink program and observing the current draw when the LED was OFF using a Fluke 287. I also made use of the Ambiq HAL & SparkFun BSP functions to attempt to place the board in a deep sleep (e.g. am_hal_sysctrl_sleep(AM_HAL_SYSCTRL_SLEEP_DEEP);). I’ve included the results of my tests below:
3.3V @ VIN
Awake: 2.8 mA
Sleep: 2.35 mA
5V @ VIN
Awake: 2.35 mA
Sleep: 1.89 mA
3.7V LiPo (4.2V) @ VBAT
Awake: 2.35 mA
Sleep: 1.88 mA
I was disappointed to see how high the quiescent draw of the board was, especially since the Artemis itself has a “1μA deep sleep mode (BLE Off) with RTC at 3.3V”. Looking at the schematic, it appears that the biggest offender is the PWR LED, which is always ON. I measured a 1.64V voltage drop across the LED, which I believe gives us a constant 1.66 mA current draw across the 1K Ohm resistor. The AP2112 LDO is also going to contribute 55 uA to the quiescent draw, but I feel like there’s other offenders I haven’t discovered as of yet (I’m looking at you: MCP73831).
I’m really keen to find a low quiescent draw QWIIC board, but I’m thinking the Artemis Nano may not be the one. Happy to hear if you’ve got any suggestions of other boards or how to decrease the quiescent draw even further!
Cheers,
Adam
Hi again Adam,
Thanks for taking the time to do some really solid measurements here to get a good idea of what the Artemis Nano will draw in different situations. We really do appreciate your work here along with your feedback about the quiescent current draw of the Artemis Development Boards.
The Nano was never designed with true low-power operation in mind, unfortunately, but, if you want to further try and reduce the current draw for your Artemis Nano, you are on the right track with disabling/removing the power LED and investigating what type of current the MCP73831 pulls without a battery attached. That should be a pretty low current draw but it’s worth checking. One other note is to try powering with 3.3V directly to the 3.3V pins since that will bypass the AP2112K 3.3V regulator. You really should not see too much being drawn by that with 3.3V applied to Vin but it’s another component that will add to the total current draw of the board. The other component to look at is the microphone. Disabling power to that will definitely help with power conservation.
As of right now, the best option we have for a dev board that has a Qwiic connector and is relatively low power is the [SparkFun Edge. We do have a new version of that with the full Artemis module onboard slated to release soon so keep an eye out for that but as far as I know, this will still have some issues for a true low-power solution since the mics and accelerometer are large current sinks (relatively speaking) and there is no easy way to disable them with this version.
Finally, I do want to again thank you for your feedback regarding the Artemis module and how we do not have a low-power option to truly showcase the abilities of the Artemis module. We have taken that along with other users’ input into consideration and actively working on another board that will allow some user-configurable options to truly get a low-power development board using Artemis.](SparkFun Edge Development Board - Apollo3 Blue - DEV-15170 - SparkFun Electronics)
Hi Mark,
Thanks very much for your reply. I appreciate your insights and suggestions for further decreasing the current draw of the Artemis Nano!
I’m very excited at the prospect of a Artemis-based board with user-configurable options that can achieve low-power operation. As my primary use is for scientific research in the Canadian Arctic, I often struggle to find components (microcontrollers, sensors, etc.) that place an emphasis on low-power operation. I believe the Artemis has a great potential for such applications and look forward to what’s coming down the pike!
Cheers,
Adam
It might be of interest that I have gotten an Artemis Blackboard down to 2.5 uA in deep sleep (see this post viewtopic.php?p=207794#p207794). It involved un-powering the microphone (about 25 uA saved), and cutting the MEAS jumper on the PCB. Cutting the MEAS jumper allows feeding 3.3V power directly to the output pin of the MEAS jumper pair so that the Artemis module gets powered, but nothing else on the board. The best part is that you are still able to plug in a USB cable. The USB cable will power the voltage regulator and USB interface and LEDs meaning that you can program the flash and interact with the board like normal. But when you remove the USB cable, only the Artemis remains powered. That might be closer to what you want. My current measurements show the Artemis drawing about 0.6 mA when running full speed doing floating point operations. A ‘normal’ sleep drops the current down to the 60 uA range, and a full-on deep sleep drops it to the 2-3 uA range. You save a lot of power by not using the on-board voltage regulator, USB interface and LEDs!
Hi Robin,
Thanks for your reply. Very interesting to see what you’ve been able to accomplish with the Blackboard!
Sounds like it’s time to start cutting traces and desoldering components! Also, many thanks for the code provided in your post. It really takes some digging to find the suitable HAL functions.
Cheers,
Adam
No desoldering is required: just two trace cuts. One for the MEAS jumper (which is designed to be cut), and the other to remove power to the microphone as shown in this post viewtopic.php?p=205882#p205882
The microphone trace is easy to locate and cut, but for any trace cutting I recommend using a brand new xacto blade!
I’m running the RTC clock demo with sleep found in the built in examples for the Artemis. Running on the Redboard with the microphone VDD and the “MEAS” jumper cut. (why did Sparkfun use the VDD to power the mic in the first place?)
The current draw as measured across the jumper test pins is still 100uA when in sleep mode. I’ve commented out all the serial write and setup lines. According to documents it should be 6uA per MHz and in sleep mode it’s supposed to be running at 3MHz…
Any thoughts?
I’ve just tried Robins demo code from above and the deep sleep current drops to the 3uA range. Very nice.
Regards,
Kevin
The “run mode” current numbers are slippery. From the data sheet pg 776, the “6 uA per MHz” spec only applies when “Executing while(1) from internal Flash Memory, cache enabled, HFRC=48MHz, all peripherals disabled, buck converters enabled, 8K SRAM, Flash1 OFF”. So basically, minimal system SRAM is powered up, half the flash turned off, no peripherals turned on. The processor will be hitting in the cache for every instruction of its while (1) loop so the flash will never be getting accessed. It’s an unlikely scenario for any real program, but serves to place a lower bound on the power you could expect to be consumed by a running processor: 288 uA (48 MHz * 6 uA/MHz). No running program you every write will take less power than that, at least at 48 MHz.
If you read the very next item in the data sheet power section describing power state ISS2, it says that the current draw is 68 uA when “WFI instruction with SLEEP=1, clocks gated, OSC’s ON, buck converters enabled, all I/O power domains powered OFF, Flash1 OFF, 8kB SRAM”. That is saying that with the CPU shut down doing nothing at all (basically in a hot standby) the current draw is 68 uA. Therefore, it seems unlikely that any power mode that involves the CPU actually executing instructions could draw less power than that: how could a processor doing something take less power than the exact same processor doing nothing? In my mind, the implication is that we don’t get to assume that a 48 MHz clock divided down to produce a 3 MHz processor clock means that the processor will be running at 3 MHz * 6 uA/MHz, or 18 uA. I think I have a bit of proof for that. My experiments to get the processor into deep sleep mode showed that turning on any part of the chip that depended on the 48 MHz oscillator caused the power to increase by about 60 uA. My assumption was that the HFRC itself takes 60 uA. A subsequent assumption would be that the HFRC would still take 60 uA no matter what you divided it down by. If all that is true, then it makes me wonder if the “per MHz” in the data sheet always refers to 48 MHz because the HFRC only ever runs at 48 MHz. That clock can be divided, but the basic osc freq is always 48 MHz. At this point, this is mostly conjecture so I think some experimentation is in order…
Robin, in your linked example that puts the artemis to deep sleep could you go the extra mile and show me how to wake it up with a 32kHz timer bringing everything back to full speed/power?
Thanks very much,
Kevin
It is on my to-do list. I got distracted by figuring out how to use the “free for non-commercial use” Segger Studio as my Artemis software development platform if only because it supports hardware debugging via their JLink interface. That all seems to be working now, so I hope to get back to the power stuff soon. In the meantime, I do enjoy single-stepping source-level and/or disassembly instructions and watching CPU registers update.
Thanks Robin. Looking forward to seeing it.
Regards
Kevin
Which JLink debug probe / interface are you using?
A JLink EDU ($60 from Sparkfun). My understanding is that the setup will also work with a JLink EDU Mini ($18 at Sparkfun), it will just be a bit slower than the more expensive one.
Much better than the ~$400-$900 dollar ones lol. BTW my Redboard draws 2.48-2.54uA and it doesn’t change when on or off the bench held in hand etc. Warming it up with fingers brings it above 2.6uA breath about the same. Using a Rigol DM3058e no averaging.
Getting to the root of “6 uA per MHz”:
Take a look at the clock diagram in the Apollo3 data sheet. If you zoom in on the part at the bottom showing where the CPU gets its clock (attached), you can see that the signal marked “hclk/fclk to CPU/SRAM/Cache” only has two possible frequencies that can be selected from the multiplexer: 48 MHz or 96 MHz. There are a total of three various divider blocks in the original diagram (only one of them is visible in the attachment), but none of the three has an output that goes to the processor/SRAM/cache. The upshot is that when the data sheet says “6 uA per MHz”, there is an implicit multiplier of 48 because the slowest the processor can run is 48 MHz. So: the lowest typical current draw that a running program could have would be 6 uA/MHz *48 MHz, or 288 uA.
In regards to a comment way earlier in this thread about a processor “running at 3 MHz”, it is clear that something inside the processor might have been getting clocked at 3 MHz, but it couldn’t have been the processor itself.
Nice find Robin. Rather devious of them I think.
All industry datasheets involve a certain amount of specmanship.
I did find something else this morning. It would appear that there is a master clock divider for HFRC where it can be divided by 2, if desired. See attached register description. The diagram of clock sources in the data sheet does not show an HFRC master divider, but if so, the processor would be capable of running at 96 MHz, 48 MHz, or 24 MHz. I’ll try to verify that today.
