nRF52840-DK only executing while debugging

I have an odd issue with an older nRF52840-DK, I can flash and read memory from the device just fine but no matter what version of NCS I use, it will not execute whatever gets flashed. However if I start a debugging session in VSCode the program executes just fine, using the blinky sample as a test software.

I can only imagine that in some past project something got flashed that set some wrong UICR values or disabled the DCDC etc.
I already did --eraseall and --recover with nrfjprog but that did not change anything. What could be going wrong here and how can I recover from this?

Parents
  • Hello,

    The symptom you describe is typically seen on custom board designs that don't include the optional 32 kHz crystal or DCDC inductors but have been programmed with a FW image that tries to use the crystal oscillator or DCDC regulator. I would not expect to see this on a DK. As a test, please try to add CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to the project configuration (prj.conf) to see if that changes anything. This changes the clock source from the default 32KHz crystal oscillator to the internal RC oscillator of the chip.

    Best regards,

    Vidar

Reply
  • Hello,

    The symptom you describe is typically seen on custom board designs that don't include the optional 32 kHz crystal or DCDC inductors but have been programmed with a FW image that tries to use the crystal oscillator or DCDC regulator. I would not expect to see this on a DK. As a test, please try to add CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to the project configuration (prj.conf) to see if that changes anything. This changes the clock source from the default 32KHz crystal oscillator to the internal RC oscillator of the chip.

    Best regards,

    Vidar

Children
  • Thank you for the fast response. I have tried adding the said config (and a few others I have found online) but after building (with nrf52DK_nrf52832 board) and flashing I still face the same issue. My config: 

    ##############################
    # BLE host + Zephyr controller
    ##############################
    
    CONFIG_BT=y
    CONFIG_BT_PERIPHERAL=y
    CONFIG_BT_DEVICE_NAME="MDBT42V_TEST"
    CONFIG_BT_DEVICE_APPEARANCE=0
    CONFIG_BT_EXT_ADV=n
    CONFIG_BT_PRIVACY=n
    CONFIG_BT_SETTINGS=n
    
    # Use Zephyr split LL controller
    CONFIG_BT_LL_SW_SPLIT=y
    CONFIG_BT_HCI=y
    
    ##############################
    # Logging via RTT
    ##############################
    
    CONFIG_LOG=y
    CONFIG_LOG_DEFAULT_LEVEL=3
    CONFIG_LOG_PRINTK=y
    
    CONFIG_USE_SEGGER_RTT=y
    CONFIG_LOG_BACKEND_RTT=y
    CONFIG_LOG_BACKEND_UART=n
    
    CONFIG_CONSOLE=y
    CONFIG_STDOUT_CONSOLE=y
    CONFIG_PRINTK=y
    CONFIG_RTT_CONSOLE=y
    CONFIG_UART_CONSOLE=n
    
    ##############################
    # Clocks – internal LFRC (no 32k XTAL wired)
    ##############################
    
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
    
    ##############################
    # Power mgmt OFF for debugging
    ##############################
    
    CONFIG_PM=n
    CONFIG_PM_DEVICE=n
    
    ##############################
    # Basic debug
    ##############################
    
    CONFIG_ASSERT=y
    CONFIG_DEBUG_OPTIMIZATIONS=y  

    My code:

    #include <zephyr/kernel.h>
    #include <zephyr/logging/log.h>
    #include <zephyr/bluetooth/bluetooth.h>
    #include <zephyr/bluetooth/hci.h>
    #include <hal/nrf_power.h>
    
    LOG_MODULE_REGISTER(test1, LOG_LEVEL_INF);
    
    static void log_reset_reason(void)
    {
        uint32_t r = nrf_power_resetreas_get(NRF_POWER);
        nrf_power_resetreas_clear(NRF_POWER, 0xFFFFFFFF);
    
        printk("RESETREAS = 0x%08x\n", r);
    }
    
    void main(void)
    {
        int err;
    
        printk(">>> ENTER main()\n");
        log_reset_reason();
    
        k_sleep(K_MSEC(1000));   // 1 second delay
        printk("After delay\n");
    
        printk("Before bt_enable()\n");
        err = bt_enable(NULL);
        printk("After bt_enable()\n");
    
        if (err) {
            printk("bt_enable failed (err %d)\n", err);
            return;
        }
    
        printk("Bluetooth enabled\n");
    
        const struct bt_data ad[] = {
            BT_DATA_BYTES(BT_DATA_FLAGS,
                          (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
            BT_DATA(BT_DATA_NAME_COMPLETE,
                    CONFIG_BT_DEVICE_NAME,
                    sizeof(CONFIG_BT_DEVICE_NAME) - 1),
        };
    
        printk("Before bt_le_adv_start()\n");
    
        err = bt_le_adv_start(BT_LE_ADV_CONN,
                              ad, ARRAY_SIZE(ad),
                              NULL, 0);
    
        printk("After bt_le_adv_start()\n");
    
        if (err) {
            printk("bt_le_adv_start failed (err %d)\n", err);
            return;
        }
    
        printk("Advertising as \"%s\"\n", CONFIG_BT_DEVICE_NAME);
    
        while (1) {
            printk("Alive\n");
            k_sleep(K_SECONDS(1));
        }
    }

    I have connected Clock, Data, VDD, VTG, GND and GND Detect of the DK to Clock, Data, VDD and GND of my MDBT42V module (with built in nrf52832)

  • It looks like there was some creeping hardware failure, after powering it up again not even the programmer comes up. Power is there but none of the chips are functional. I guess this is a dead board.

  • Likely only needs to apply "Interface MCU firmware" again. Note: Website search can't currently find it, its in the downloads for the specific DK.

    On older DKs this gets de-activated every time you hold "Reset" button down during power-on sequence and will require a re-upload.

    Big indication is "no led lights up" when you connect the USB cable.

  • there is no USB device coming up, if its still alive that would probably have to be flashed via SWD?

  • ok yea nvm the bootloader still worked, holding reset while powering on brought up the OB bootloader and reflashing it brought it back to life. The nRF52 itself still behaving weird as before but at least the board is alive

Related