Sleep mode current consumption fluctuating
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- cpp, raspberry-pi
- Domain
- embedded-iot
Research direction
Start with the DeepSleep::launch and DeepSleep::recover entry points in the provided deep_sleep.h-based code, and reproduce the fluctuation using the minimal sleep-loop program described. Compare the current draw across successive sleep_goto_sleep_until calls and check the Pico datasheet and the linked dormant-mode report. Done means identifying why consumption changes and documenting or implementing a reliable correction.
Written by the indexing model from the issue text.
Description
When I enter sleep mode (not dormant mode) the current consumption of my Pico is unreliable. I can successfully enter and exit sleep mode and I enable all necessary clocks I believe:
#include "deep_sleep.h"
uint scb_orig;
uint en0_orig;
uint en1_orig;
void DeepSleep::recover() {
// Re-enable ring oscillator control
rosc_write(&rosc_hw->ctrl, ROSC_CTRL_ENABLE_BITS);
// reset procs back to default
scb_hw->scr = scb_orig;
clocks_hw->sleep_en0 = en0_orig;
clocks_hw->sleep_en1 = en1_orig;
// reset clocks
clocks_init();
set_sys_clock_khz(133000, true);
}
void DeepSleep::launch(int8_t minutes, int8_t seconds) {
if (minutes < 0 || minutes > 59 || seconds < 0 || seconds > 59) {
return;
}
// save current values for clocks
scb_orig = scb_hw->scr;
en0_orig = clocks_hw->sleep_en0;
en1_orig = clocks_hw->sleep_en1;
sleep_run_from_xosc();
datetime_t t = {
.year = 2024,
.month = 01,
.day = 27,
.dotw = 1,
.hour = 12,
.min = 00,
.sec = 00
};
datetime_t t_alarm = {
.year = 2024,
.month = 01,
.day = 27,
.dotw = 1,
.hour = 12,
.min = minutes,
.sec = seconds
};
// Start the RTC
rtc_init();
rtc_set_datetime(&t);
sleep_goto_sleep_until(&t_alarm, &recover);
}
I can then enter sleep mode by calling DeepSleep::launch(0, 10) in order to sleep for, in this case, 10 seconds.
Whenever I do this the current consumption is often as low as 1.3mA the first time I enter deep sleep, successive calls however often cause a higher current consumption of about 4mA. Does anyone know why? Its also really hard to tell when this problem occurs, I tested this on a Pico without any sensors connected. I also tried a super simple program where the Pico only goes into deep sleep over and over again, and it appears to happen less, but occasionally it still happens. And once the current draw is the higher one in sleep mode it keeps being this high, like it never returns to only drawing the 1.3mA in sleep mode, which is also really odd.
I found one related post that seems to be experiencing the same problem, albeit being in dormant mode: https://forums.raspberrypi.com/viewtopic.php?t=336273
Maybe theres some hardware features that aren't always turned off? I tried looking through the datasheet, but couldn't find a solution...
Help would be much appreciated!
- Dominant language
- No language data
- Stars
- 35
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from raspberrypi/pico-feedback
-
documentation hardware pdf
Difficulty 1/5 Under an hour Newbie friendliness 92/100
raspberrypi/pico-feedback#503 ·
-
documentation pdf
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
raspberrypi/pico-feedback#485 ·
-
documentation rp2350
Difficulty 1/5 Under an hour Newbie friendliness 88/100
raspberrypi/pico-feedback#478 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
raspberrypi/pico-feedback#390 ·
-
documentation pdf rp2040 rp2350
raspberrypi/pico-feedback#501 · 1 comment · 1 assignee ·
All issues in raspberrypi/pico-feedback
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
espressif/esp-iot-solution#786 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100