4
\$\begingroup\$

I have an ATmega328P running at 16 Mhz on CR2032 with a few sensors and radio for about a week now. It started out at 3+ Volts and is currently measuring at 2.96 Volts. At present, I am not using boost regulators to regulate this. I use the low power sleep mode using the jee lib libraries, sleep for a few seconds then wake up for less than a second, take a few readings, transmit and go back to sleep again.

Of late, I noticed that the sleep duration had shrunk by a few orders of magnitude. It seems to sleep for ~50 or so milli-sec, instead of the 5 sec sleep that it used to work at. If I switch to the 2xAA (2.84 Volts), I still get the full 5 sec sleep cycle.

Is this behavior due to the ATmega328P switching back to use the internal 8 MHz instead of the external 16 MHz? Also not sure how the timing/sleep works fine with 2xAA at 2.84 Volts but not with CR2032 at 2.96 Volts?

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Instead of the intended sleep, you might be experiencing a repeating cycle of brownout and reset. Try watching the supply voltage with a scope. \$\endgroup\$
    – Chris Stratton
    Commented Aug 8, 2014 at 3:51

2 Answers 2

Reset to default
2
\$\begingroup\$

A few things. You are most likely measuring the battery at no load. Even if connected and running, a multimeter does not see quick power draws. An oscilloscope is needed for millisecond power draws. Remember, CR2032s are designed for low current long term usage. 250mAh @ a few mA. Your micro and sensors coming out of sleep causes inrush, and the CR2032's high ESR (equivalent series resistance) as causes voltage droop. Do you have a decoupling capacitor in parallel close to the power pins?

And voltage drops won't make the ATmega drop down to a slower speed. That's too advanced a feature for most lowly micros. It will continue to try running at 16MHz, with an unstable clock. Brownouts are likely.

You could run the ATmega at 8MHz for all voltages to avoid the issue, and adjust your delays/timers based on that.

\$\endgroup\$
3
  • \$\begingroup\$ Thanks for the info. Yep, Voltages were measured at no load. I did try out a few decoupling capacitors - 1uF, 10uF (couldn't get hold of a 0.1uF) but they didn't change the output behavior. I use the low power nrf24l01+ radio and tmp36 sensor.. and they appear to have very low current needs. Currently ATmega328p-pu is running the Arduino Uno bootloader. Would you happen to know if I use the 8 MHz boot loader I could still use the same ATmega commands that utilize the low power sleep modes (jeelabs.net/pub/docs/jeelib/classSleepy.html)? \$\endgroup\$
    – user46743
    Commented Jul 3, 2014 at 18:29
  • \$\begingroup\$ You should, just divide your expected delay times by half then test. (Half the clock, it takes twice as long to count to the same number) \$\endgroup\$
    – Passerby
    Commented Jul 3, 2014 at 21:20
  • \$\begingroup\$ Here an article about a project using a CR2032 as power source: hackster.io/Talk2/… \$\endgroup\$
    – Talk2
    Commented Dec 13, 2016 at 4:58
7
\$\begingroup\$

It looks like you're running the MCU outside the safe operating area with a coin cell. According to the ATmega328P datasheet, page 316, the minimum safe supply voltage for 16MHz is around 3.8V (the red markings are mine). You should expect to see erratic behavior in that case. In practice, you're just overclocking your MCU. See what Russell McMahon has to say about this.

ATmega328P safe operating area

As for the AA vs. coin cell question, it has to do with the fact that AAs have a much higher discharge rates (AAs can deliver a few amps). Coin cells (see a sample datasheet) may deliver up to a few mA for short pulses.

\$\endgroup\$
5
  • \$\begingroup\$ Thank you for the info. I did realize it was out of spec for this test but the results appeared to have a pattern unlike the values that I usually get when I lower the voltages further down and force a brown-out. So was trying to figure out if it tries to switch down and operate @ 8 MHz before it throws in the towel. \$\endgroup\$
    – user46743
    Commented Jul 3, 2014 at 18:56
  • \$\begingroup\$ Right. As Russel says mockingly in his post (which I linked), by going past the specs, you'll be venturing in unknown territory. As you test the MCU limits, things may seem to work, but you may get erratic behavior when you least expect. By the way, I hope you didn't take offense me linking to Russel's answer, as it's a bit too humorous - but it does illustrate my point well. \$\endgroup\$
    – Ricardo
    Commented Jul 3, 2014 at 19:19
  • \$\begingroup\$ But no, the ATmega won't change its clock. It would be useful if it did, but it just gives up in unexpected ways. \$\endgroup\$
    – Ricardo
    Commented Jul 3, 2014 at 19:20
  • \$\begingroup\$ Thanks for the link. No offense, not at all. Concise and clear explanation. The link was pretty funny and informative, as well. I just wish stackexchange had a feature to mark more than one solution as an acceptable answer. \$\endgroup\$
    – user46743
    Commented Jul 3, 2014 at 19:23
  • \$\begingroup\$ No sweat. Mark whatever answer you find most useful to you. Other's may vote differently, but accepting the answer is your choice :D \$\endgroup\$
    – Ricardo
    Commented Jul 3, 2014 at 19:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.