#RP2350 Deep Sleep

1 messages · Page 1 of 1 (latest)

devout wadi
#

@stuck escarp Continuing our discussion re: RP2350 deep sleep. If it is possible to source AON from XOSC in dormant mode, it might make sense to selectively turn off XOSC when deep sleeping only on a GPIO pad. And, of course, document that behavior. That way for additional power savings, an app could use an external clock chip tied to a pin for accurate timing while not incurring the cost of running the XOSC.

stuck escarp
#

For waking on a pin transition, you could avoid XOSC being on. For external wakeups from an RTC, turning off XOSC could work. But the latter will not be a common use case. But I would say don't try to add a bunch of features now, unless XOSC is high consumption. Getting the 80-90% use cases now is better, and further features could be added. Main thing is getting accurate TimeAlarm to work and getting PinAlarm to work.

devout wadi
#

In light of this from section 12.10.1 of the datasheet, XOSC likely isn't an option: "When the chip core is powered, the tick source can be switched to
the on-chip crystal oscillator (XOSC) for greater precision." Since the core isn't powered in P1.0, we'd need to stay in, at best, P0.3.

#

I'll gather some numbers and go from there.

devout wadi
#

@stuck escarp Some limitations on what we can do with power states:
o The lowest power state we can use is P1.4 where SWCORE and XIP power domains are switched off. The SRAM domains need to be kept on to preserve sleep memory.
o With a time alarm in effect, the lowest power state we can use is P0.0 (SWCORE, XIP, and SRAM powered), otherwise, we cannot use XOSC as the AON timer source because it's part of the SWCORE power domain.

stuck escarp
devout wadi
#

Maybe a reasonable threshold on timer alarms? Say 60 seconds or less uses LPOSC, otherwise XOSC?