-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adafruit Feather M0 Basic Proto consumes 1mA current even in DeepSleep. Hardware issue or Software? #17
Comments
the neopixel takes about a mA in quiescent, so not surprising. |
@ladyada Sorry, I didn't describe the board properly. It's a M0 basic proto, without a neopixel. |
still possible, we haven't dont any measurements, there's the battery charger that could draw current |
@ladyada Got it. I'll share the results after removing the charger. |
@ladyada So, I removed the LDO, charging IC, battery sense resistors, resistors connected to enable pin and status pin, the protection diode.. Here are the remaining components: The power consumption is still too high. It's 0.75mA at 3V3 external supply and 0.47mA at 3V external supply. At 2.5V the micro becomes unstable, waking up sooner than expected. I'm hoping to use this for a long-term battery powered application mainly as a RTC+micro combo instead of having to use an external RTC. Not sure what I'm doing wrong here. [UPDATE] Tested with a different meter to confirm the current measurement. Same results. |
@ladyada I'm requesting you to reopen this issue. The issue doesn't seem to be resolved. |
we can reopen the issue but we dont have a fix and we're unlikely to get to this any time soon so you may have to try to figure it out on your own! |
Can try setting the Power Manager IDLE value to 1 or 2 before calling sleep(), see if any difference (default is 0): If no change, or not sufficient change, you might need to disable individual peripherals. Some info on each peripheral's power consumption in this app note: |
Yeah, I got the impression that this would not be trivial. I'll try changing the IDLE value and report the results. It'll be nice to figure it out though. I'm sure there would be many uses for ultra-low power M0 feathers... |
Does the project you have in mind absolutely require M0 capabilities? Normally I wouldn't recommend an AVR for much of anything these days, but at least the low-power stuff is simple and well understood. The "Flying Toaster jewelry" project and TimeSquare watch both make pretty effective use of this (latter can go something like 9 months on a coin cell battery). |
I was hoping to use the DAC to play some music, that's the only thing I need the M0 for. Other than that it's just driving a motor and reading a few buttons. I know I can use an MP3 shield, but a one-chip solution seemed elegant. |
Isn't MCU power draw a drop in the bucket compared to speakers & motors? Even without sleep. |
The device is a TimeLock GiftBox. The idea is that you code it with a time and date to wake up and it drives a motor to lock the box. Then it sleeps for a few months only waking up to check the RTC or have some sort of alarm on the RTC to wake up the device. Then it drives the motor to open the box at the assigned time and plays 'happy birthday to you' or some such music. Then goes to sleep indefinitely. If the device sleeps for two months, and the micro consumes 750uA in deep sleep that's 1080mAh definitely not trivial. Ideally I want it to function for a year with ~20% of battery capacity left. With AA cells it needs to be ~200uA or less in deepSleep. |
@tinkrmind While I think this is a cool idea, I'm guessing you've already realized that just a micro isn't great for this solution. Since your info on the processor has helped me in random research, I wanted to share an idea to solve your problem. Use a PCF8523 connected to the MCU and use a FET to disconnect power to the MCU until the RTC alarm interrupt pin is triggered. You can manually override it to have the MCU configure the RTC with the correct time and set the alarm time. You can configure the alarm to happen at a particular time on a day of the month, so then the micro wakes up it can check the RTC to see if the full date matches, and if not reset the alarm putting the micro back into effective 0uA sleep. That should get you over a year with a coin cell. |
@tinkrmind In case you haven't figured out the solution to this problem, the issue is in the Adafruit Feather M0 board definitions. The SAMD21 pins are tri-stated by default, which is their lowest power consumption configuration (Section 42.6 of SAMD21 manual). Adafruit chooses to initialize all digital and analog pins as inputs, which is the source of the high quiescent draw observed in deep sleep. To prevent this from happening, you can comment out the following code in the wiring.c file:
I was able to achieve a quiescent draw of 86.2 uA after commenting out the above code with a Feather M0 Proto. This is an expected value given the AP2112's regulator draw of ~50 uA and the 100/100 kOhm resistive voltage divider draw of ~20 uA. After replacing the AP2112 with a MIC5225 and slightly changing the voltage divider to 330/100 kOhm, I was able to reach ~26 uA. I love Adafruit products but they certainly do not emphasize low-power operation. |
ooh thats interesting! @adamgarbo can you submit a PR to have that commented out in our samd board def repo? that would be super rad |
Comment out the initialization of all SAMD21 pins to INPUT to allow them to remain tri-stated by default. See adafruit/Adafruit_SleepyDog#17 (comment)
Comment out the initialization of all SAMD21 pins to INPUT to allow them to remain tri-stated by default. See adafruit/Adafruit_SleepyDog#17 (comment)
@adamgarbo After commenting out the code in wiring.c, how do I use that version instead of the standard version used for the board? |
I know this is older, but since its still open, I thought I'd add my "solution". |
@asada03 Sorry, I must have missed your comment. Adafruit has made the change to their board definitions so that pins are no longer initialized as INPUTs. There's nothing you need to do if you have the most up-to-date version of the board definition. Out of the box, a Feather M0 Proto averages around ~80 uA when in deep sleep (~60 uA for the AP2112 and 20 uA for the 100/100 kOhm voltage divider). @marc-gist Interesting suggestion, thanks! @tinkrmind I believe you can close this issue now. |
I realize I'm coming late to this, and perhaps am missing something obvious, but i'm struggling with a similar issue with an Itsybitsy M0 Express. After using Sleep example code from SleepyDog (adding code to turn off the Dotstar), i get a current draw of ~1.3mA from the board when asleep. Using the same code, but using pin_mode() to define pins 0-31 as OUTPUT in setup, i get a sleep current of ~0.75mA. Because the current is lower when the pins are defined as OUTPUT, this suggests to me that the pins are initially defined as input. However, in wiring.c file i see the definition of pins as INPUT as commented out (path is /Arduino15/packages/adafruit/hardware/samd/1.5.3/cores/arduino/wiring.c). Why does changing the pin mode affect the current use, if the board is initialized with tri-state pin definitions, as per the wiring.c and @adamgarbo comment above? Any other suggestions for dropping the sleep current on this board? Thanks for any help you can provide! |
@kjloope I expect that 0.75 mA is likely as good as you're going to get for a sleep current with the ItsyBitsy M0 Express. Both the DotStar Micro LED and unnamed SPI Flash chip are tied to 3.3V. While the Flash can probably be put to sleep, you're stuck with the LED power consumption unless you cut the trace or remove it with a hot air rework station. |
OK, thanks for your reply. |
@adamgarbo Removing the DotStar seems to have improved it quite a bit! Down to <0.1mA, measured with an INA219. Thanks again for your help. |
Same here. I've been using Feather m0 LoRa using deep sleep with the RTCzero library and I'm operating at 2.4 mA. I went to the wiring.c file and as @kjloope stated, I found the code specified by @adamgarbo was already commented out. I am going to change my pins to output as @kjloope did and see what happens. |
Adafruit addressed the issue of not setting the pins to INPUT in PR #98. It's important to note that this thread was originally focused on the Feather M0 Proto. There's no guarantee that any of the other M0-based Feather boards will be able to achieve a similarly low quiescent draw. They will need to be assessed on a case-by-case basis to identify the sources of power consumption. Historically, Adafruit has not prioritized extremely low sleep currents in their designs, which often necessitates the cutting of traces or removal of components with a hot-air rework station. |
Thank you @adamgarbo, I appreciate your reply. Good luck & stay safe. |
@kjloope. Could you please tell me how to put the SPI Flash chip to sleep? |
Hi @Luckyman90, Sorry, but I don't have any insight here. Anything i
learned a couple years ago is gone from my brain, and I don't think I ever
achieved the sleep i was hoping for back then. Good luck!!
…On Mon, Apr 3, 2023 at 12:49 AM Luckyman90 ***@***.***> wrote:
@kjloope <https://github.com/kjloope> I expect that 0.75 mA is likely as
good as you're going to get for a sleep current with the ItsyBitsy M0
Express. Both the DotStar Micro LED and unnamed SPI Flash chip are tied to
3.3V. While the Flash can probably be put to sleep, you're stuck with the
LED power consumption unless you cut the trace or remove it with a hot air
rework station.
@kjloope <https://github.com/kjloope>. Could you please tell me how to
put the SPI Flash chip to sleep?
—
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACUIU5BWXQIZYWG4TIKLBMDW7JJGXANCNFSM4GG75XOQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
[EDIT: the board is Feather M0 Basic Proto]
Arduino board: Adafruit Feather M0 Basic Proto
Arduino IDE version (found in Arduino -> About Arduino menu): 1.8.5
List the steps to reproduce the problem below (if possible attach a sketch or
copy the sketch code in too):
I was expecting the board to consume <100uA. It doesn't seem like there are any external components that would be consuming power. Should I remove the power management chips to see if that resolves the problem? Just wanna make sure this isn't a known issue before I take the soldering iron to this pretty board.
The text was updated successfully, but these errors were encountered: