Waking up from deep sleep on a Clue triggers safe mode

[bmustill-rose]

CircuitPython version

Adafruit CircuitPython 7.3.0 on 2022-05-23; Adafruit CLUE nRF52840 Express with nRF52840
Board ID:clue_nrf52840_express

Code/REPL

import alarm
import board
from adafruit_clue import clue

print("We're here!")
clue.play_tone(880, 0.5)

clue._a.deinit()
clue._b.deinit()
paa = alarm.pin.PinAlarm(pin=board.BUTTON_A, value=False, pull=True) 
pab = alarm.pin.PinAlarm(pin=board.BUTTON_B, value=False, pull=True) 
alarm.exit_and_deep_sleep_until_alarms(paa, pab)

Behavior

You are in safe mode because:
CircuitPython core code crashed hard. Crikey!
Attempted heap allocation when VM not running.

Description

I'm finding that waking up from a pin alarm on a Clue triggers safe mode.

I'm running:

UF2 Bootloader 0.6.4 lib/nrfx (v2.0.0) lib/tinyusb (0.12.0-145-g9775e7691) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: Adafruit CLUE nRF52840
Board-ID: nRF52840-CLUE-revA
Date: May 17 2022
SoftDevice: S140 6.1.1
adafruit-circuitpython-clue_nrf52840_express-en_GB-7.3.0
adafruit-circuitpython-bundle-7.x-mpy-20220610 (only the libraries that are required for the clue module are present)

See the code snippet for an example that replicates the problem.

Looking at the serial output "Woken up by alarm." is printed although straight after the Clue disconnects reconnecting as clueboot.
After resetting the Clue, the relevant parts of the serial output are:
You are in safe mode because:
CircuitPython core code crashed hard. Crikey!
Attempted heap allocation when VM not running.

I'll be more than happy to provide any additional info or do any further testing if required.

Additional information

No response

[DavePutz]

Looks like the issue is the raising of the message "All SPI peripherals are in use" while initializing SPI:
Stack trace shows:

#0  reset_into_safe_mode (reason=reason@entry=GC_ALLOC_OUTSIDE_VM) at ../../supervisor/shared/safe_mode.c:121
#1  0x00048cf8 in gc_alloc (n_bytes=n_bytes@entry=16, alloc_flags=alloc_flags@entry=0, long_lived=<optimized out>)
    at ../../py/gc.c:525
#2  0x00084f42 in m_malloc_maybe (num_bytes=num_bytes@entry=16, long_lived=long_lived@entry=false)
    at ../../py/malloc.c:103
#3  0x000546d4 in mp_obj_new_exception_msg_vlist (exc_type=0x9ebd4 <mp_type_ValueError>, fmt=0xa8f78 <v>,
    fmt@entry=0xaa8a4 <pin_P0_15>, ap=..., ap@entry=...) at ../../py/objexcept.c:432
#4  0x00087162 in mp_obj_new_exception_msg_varg (exc_type=<optimized out>, fmt=0xa8f78 <v>)
    at ../../py/objexcept.c:420
#5  0x0008714e in mp_obj_new_exception_msg (exc_type=<optimized out>, msg=<optimized out>) at ../../py/objexcept.c:379
#6  0x00087892 in mp_raise_msg (exc_type=<optimized out>, msg=<optimized out>) at ../../py/runtime.c:1630
#7  0x00056f3e in mp_raise_ValueError (msg=<optimized out>) at ../../py/runtime.c:1678
#8  0x00037470 in common_hal_busio_spi_construct (self=self@entry=0x20010920 <displays+8>, clock=0xaa89c <pin_P0_14>,
    mosi=0xaa8a4 <pin_P0_15>, miso=miso@entry=0x0, half_duplex=half_duplex@entry=false) at common-hal/busio/SPI.c:162
#9  0x00032e0a in board_init () at boards/clue_nrf52840_express/board.c:51
#10 0x00067022 in run_code_py (safe_mode=safe_mode@entry=NO_SAFE_MODE, first_run=first_run@entry=true,
    simulate_reset=simulate_reset@entry=0x2003ffdf) at ../../main.c:675
#11 0x0004d2f6 in main () at ../../main.c:924

[tannewt]

I bet we need to deinit the display in board_deinit.

[DavePutz]

@tannewt - that would probably work, but that means we would have to put code there for every NRF board in case they had something on the SPI bus. Would it possibly be better to have a flag in common_hal_busio_spi_construct() saying whether spi has been initialized and exiting out if it was done once already?

[tannewt]

We could have it return a bool rather than raise an exception but it'll still be an error in the C code. Most SPIs will be reset before the sleep. Only displays generally live longer.

[bmustill-rose]

It's great to see that a fix for this has already been merged - very impressive! I'm guessing from the 7.3.x milestone that there'll be another 7x release before 8; does anyone have a rough idea of when that might be? Many thanks.

[tannewt]

It's great to see that a fix for this has already been merged - very impressive! I'm guessing from the 7.3.x milestone that there'll be another 7x release before 8; does anyone have a rough idea of when that might be? Many thanks.

@dhalbert Is planning a 7.3.1 soon. Not sure if it'll have this fix. You should be able to use "Absolute Newest" builds just fine. Nothing major has happened on main yet.

[dhalbert]

I will backport this to 7.3.x. Sounds like a good thing to get in.