Are sleep modes supported on nRF52832?

[cwalther]

I have recently started playing with MicroPython on an nRF52832 (1.22.0-preview compiled from source), after previously using it mainly on ESP microcontrollers. I am not familiar with the nRF52 and find the MicroPython documentation a bit lacking compared to other ports.

The board I’m using is a DS-D6 fitness tracker and I am working on the REPL via the UART on pins 22 & 23.

Right now I am trying to use low-power modes, which seems important on a small battery-powered device. Does MicroPython on the nRF52832 support any low-power modes, and how do I use them?

My somewhat confusing empirical results so far are:

• machine.lightsleep() does not appear to do anything. If it sleeps at all, which I can’t tell, then only for a split second until it is woken up again by I don’t know what (maybe background activity from the SoftDevice?). This seems more like what machine.idle() is supposed to do.

• Right after a hardware reset, machine.deepsleep() does sleep, however it’s a light sleep (which resumes where it left off), not a deep sleep (waking from which would be a reset). I can wake it up using the touch button, which pulls pin 30 low, although I didn’t explicitly set up anything about that pin, and by sending input on the UART (which also pulls a pin low, so maybe it’s the same mechanism).

• Once I turn on the SSD1306 display, which involves setting up machine.SPI(0) and a couple of machine.Pins, machine.deepsleep() stops working, it wakes up again right away. This persists over a soft reset (^D). The only way I have found so far of getting back into a state where deepsleep() works is machine.reset(). Is there a way around this?

I can look at the source code and see that lightsleep() and deepsleep() are implemented as WFE and WFI, but I’m not familiar enough with ARM microcontroller internals to know what that means exactly and how to use it.

Some preliminary googling indicates that the nRF52 does have a real deepsleep, called “System OFF”. Is there a way to enter this from MicroPython, other than poking around with machine.mem32? And to set up wake sources for it?

[robert-hh]

Looking into the nrf code I agree that both deepsleep() and lightsleep() are kind of dummy functions, just to provide a method with that name. __WFE() is wait for event, __WFI is wait for interrupt. Both interrupt and event happen on most ports after latest 1 ms. So there is not much of a sleep

[cwalther]

Thanks for the confirmation, Robert.

I’ve made a bit of progress on two fronts:

• The case of the working/non-working deepsleep: It has nothing to do with the display after all, that was a red herring because the display initialization includes a time.sleep_ms() call. The actual difference is between a hard reset and a soft reset. After a hard reset (power-on or machine.reset()), it seems like the RTC counter is erroneously not running. That makes deepsleep() sleep indefinitely, but it also makes time.ticks_ms() always return 0 and time.sleep_ms() get stuck indefinitely (though you can interrupt it with ^C). After a soft reset (^D), the time functions work as they should, and deepsleep() wakes immediately. In fact, reading mphalport.c, WFI is supposed to wake every millisecond, which makes it totally unsuitable for deepsleep(). I wonder if WFE should be moved into machine.idle(), WFI into machine.lightsleep(), and machine.deepsleep() do something else entirely (see below). As for what causes the bug I’m not sure yet. It seems like the RTC is set up by rtc1_init_time_ticks(), which is called from main() in both the hard and soft reset cases, so maybe some other initialization turns it off again? I’ll probably have to dig up my SWD debugger Raspberry Pi to figure that out.

• After reading a bit in the nRF52832 Product Specification, I am able to enter “System OFF” (the real deepsleep) using

# NRF_POWER->SYSTEMOFF
machine.mem32[0x40000500] = 1

However, I can’t wake up after that. I thought I had configured pin 30 going low as a wake source for that using

# NRF_P0->PIN_CNF[30].DIR=Input, .INPUT=Connect, .PULL=Pullup, .DRIVE=S0S1, .SENSE=Low
machine.mem32[0x50000778] = 0b110000000000001100
# NRF_P0->DETECTMODE = Default
machine.mem32[0x50000524] = 0

but tapping the button doesn’t wake it up. 🤔 Do I have to set up anything else to enable DETECT as a wake source? The SENSE configuration seems correct, as I can see its effect in the LATCH register. (Interestingly, PIN_CNF[30] was already set up like that to begin with. I wonder who did that.) I can’t be totally sure that the touch sensor is working during deep sleep, but unfortunately I’d have to disassemble the device further to get direct access to the pin.

[cwalther]

After a hard reset (power-on or machine.reset()), it seems like the RTC counter is erroneously not running.

I fixed this: #13339.

[cwalther]

I am able to enter “System OFF” (the real deepsleep) … but tapping the button doesn’t wake it up

Okay, figured out that one too. It’s actually working. It does in fact wake up, but the bootloader then also checks the button, and if it’s touched, goes into Bluetooth DFU mode instead of starting the application. (It times out after 5 minutes and proceeds though.) That is unfortunate, but I’m not picking the battle of modifying the bootloader right now. I can work around it by instead configuring pin 22, the UART RX on the USB plug, as the wakeup source, and waking it by either sending something to the UART or shorting the two adjacent pins on the USB plug.

Here’s my attempt at a Python API: #13367.