nrf52840 (clue): DEBUG=1 build not booting

[jepler]

I built at 7.0.0-alpha.2-584-g25a44cb77 with DEBUG=1, and got a red light and no CIRCUITPY drive. With DEBUG=0 or the binary from s3, it works. This makes me think that DEBUG=1 is broken at least for clue and possible for other nRF52s.

[DavePutz]

Reproduced this on a feather_nrf52840_express. Hooked up a debugger and captured this stack:

#0  reset_into_safe_mode (reason=reason@entry=MICROPY_FATAL_ERROR) at ../../supervisor/shared/safe_mode.c:119
#1  0x00045374 in __fatal_error (msg=msg@entry=0x99610 "Assertion failed") at ../../main.c:802
#2  0x0004538c in __assert_func (file=file@entry=0xa119c "./nrfx/hal/nrf_gpio.h", line=line@entry=474,
    func=func@entry=0xa16fc <__FUNCTION__.8463> "nrf_gpio_pin_port_decode",
    expr=expr@entry=0xa1184 "*p_pin < NUMBER_OF_PINS") at ../../main.c:809
#3  0x00052dd2 in nrf_gpio_pin_port_decode (p_pin=<synthetic pointer>) at ./nrfx/hal/nrf_gpio.h:523
#4  nrf_gpio_cfg (sense=NRF_GPIO_PIN_NOSENSE, drive=NRF_GPIO_PIN_S0S1, pull=NRF_GPIO_PIN_NOPULL,
    input=NRF_GPIO_PIN_INPUT_DISCONNECT, dir=NRF_GPIO_PIN_DIR_INPUT, pin_number=1233133628)
    at ./nrfx/hal/nrf_gpio.h:521
#5  nrf_gpio_cfg_default (pin_number=1233133628) at ./nrfx/hal/nrf_gpio.h:557
#6  nrfx_twim_uninit (p_instance=p_instance@entry=0x20010484 <twim_peripherals+12>)
    at nrfx/drivers/src/nrfx_twim.c:313
#7  0x00059334 in i2c_reset () at common-hal/busio/I2C.c:64
#8  0x00045572 in reset_port () at supervisor/port.c:219
#9  0x0004529a in main () at ../../main.c:701

Not sure where that invalid pin_number is coming from; will investigate further.

[DavePutz]

Re-tested this on 7.0.0-alpha.4 and got a different stack:

#0  reset_into_safe_mode (reason=reason@entry=GC_ALLOC_OUTSIDE_VM) at ../../supervisor/shared/safe_mode.c:123
#1  0x000287ce in gc_alloc (n_bytes=n_bytes@entry=16, alloc_flags=alloc_flags@entry=0, long_lived=<optimized out>)
    at ../../py/gc.c:508
#2  0x00027dc8 in m_malloc_maybe (num_bytes=num_bytes@entry=16, long_lived=long_lived@entry=false)
    at ../../py/malloc.c:103
#3  0x00037636 in mp_obj_new_exception_msg_vlist (exc_type=0x98458 <mp_type_ValueError>, fmt=0xa20bc <v>,
    fmt@entry=0x0, ap=..., ap@entry=...) at ../../py/objexcept.c:425
#4  0x00037726 in mp_obj_new_exception_msg_varg (exc_type=<optimized out>, fmt=0xa20bc <v>)
    at ../../py/objexcept.c:413
#5  0x00037736 in mp_obj_new_exception_msg (exc_type=<optimized out>, msg=<optimized out>) at ../../py/objexcept.c:372
#6  0x00032c76 in mp_raise_msg (exc_type=<optimized out>, msg=<optimized out>) at ../../py/runtime.c:1601
#7  0x00032dce in mp_raise_ValueError (msg=<optimized out>) at ../../py/runtime.c:1649
#8  0x0005947a in check_nrf_error (err_code=7) at common-hal/_bleio/__init__.c:56
#9  0x00059288 in common_hal_bleio_service_add_characteristic (self=0x20012254 <supervisor_ble_serial_service>,
    characteristic=characteristic@entry=0x20012224 <supervisor_ble_rx_characteristic>,
    initial_value_bufinfo=initial_value_bufinfo@entry=0x0,
    user_description=user_description@entry=0xa3190 "CircuitPython Serial") at common-hal/_bleio/Service.c:176
#10 0x00057798 in common_hal_bleio_characteristic_construct (
    self=self@entry=0x20012224 <supervisor_ble_rx_characteristic>,
    service=service@entry=0x20012254 <supervisor_ble_serial_service>, handle=handle@entry=0,
    uuid=uuid@entry=0x2001224c <supervisor_ble_rx_uuid>, props=props@entry=48 '0',
    read_perm=read_perm@entry=SECURITY_MODE_NO_ACCESS, write_perm=write_perm@entry=SECURITY_MODE_ENC_NO_MITM,
    max_length=max_length@entry=512, fixed_length=fixed_length@entry=false,
    initial_value_bufinfo=initial_value_bufinfo@entry=0x0,
    user_description=user_description@entry=0xa3190 "CircuitPython Serial") at common-hal/_bleio/Characteristic.c:129
#11 0x0004bb28 in supervisor_start_bluetooth_serial () at ../../supervisor/shared/bluetooth/serial.c:83
#12 0x0004b1d2 in supervisor_start_bluetooth () at ../../supervisor/shared/bluetooth/bluetooth.c:233
#13 0x00045698 in main () at ../../main.c:811

[jepler]

Re-tested this on 7.0.0-alpha.4 and got a different stack:

This new traceback may be #5018

[tannewt]

I think this is two separate issues. The first is due to us trying deinit objects that we never initialized. The pin_number is invalid because it was never set.

I've been hunting the second one as well and will reply on #5018.

[tannewt]

Does this still happen for folks? I can't replicate it now.

[DavePutz]

See my comment in issue #5018.

…

On Wed, Jul 28, 2021 at 7:19 PM Scott Shawcroft ***@***.***> wrote: Does this still happen for folks? I can't replicate it now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4768 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNJKEVQQDSPXAEGO2VVBYLT2CNARANCNFSM446MF2FA> .

[tannewt]

How did you all copy the build over? UF2? I suspect the bootloader is failing on images >512k in size (1MB+ uf2 file). adafruit/Adafruit_nRF52_Bootloader#213

[DavePutz]

I have been using the uf2 bootloader. I just loaded a debug 7.0.0-alpha.5 build on a Feather nrf52840 Express using a jlink connection and it booted correctly. The .uf2 size was 1127936 bytes.

…

On Mon, Aug 2, 2021 at 5:01 PM Scott Shawcroft ***@***.***> wrote: How did you all copy the build over? UF2? I suspect the bootloader is failing on images >512k in size (1MB+ uf2 file). adafruit/Adafruit_nRF52_Bootloader#213 <adafruit/Adafruit_nRF52_Bootloader#213> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4768 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNJKEUVNOH2YPXDQZ4VJULT24IVPANCNFSM446MF2FA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[tannewt]

Thanks @DavePutz. Let's consider this fixed.