This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bootloader Resets Once Right After Program

I am running SDK 15.2 on an nRF52840. I have programmed my secure dfu bootloader, application, settings.hex, and softdevice via jtag. During the first run after programming the bootloader runs, resets, runs, and then successfully executes my application. This reset only occurs on the first run after programming the bootloader. I am trying to understand why this reset is occurring. I was thinking it had something to do with the master boot record not being initialized. Either that or possibly something with my settings.hex. I think settings.hex is less likely but here how I am creating it.

nrfutil settings generate --family NRF52840 --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex

Parents Reply Children
  • I suggest you enable nrf_log for the bootloader, and try to find the reason for the reset by logging, if you are not already doing that. Nrf_log can be enabled in sdk_config.h.

  • I get the same results with the SDK example, secure_bootloader_ble_s140_pca10056_debug, unmodified. See the two <info> app: Inside main below. It appears to be trying to load the application but then fails, resets, and then successfully loads it.

    <info> app: Inside main
    <debug> app: In nrf_bootloader_init
    <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    <debug> nrf_dfu_settings: Settings OK
    <debug> app: Enter nrf_bootloader_fw_activate
    <info> app: No firmware to activate.
    <debug> app: Enter nrf_dfu_app_is_valid
    <debug> app: Return true. App was valid
    <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
    <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.<info> app: Inside main
    <debug> app: In nrf_bootloader_init
    <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    <debug> nrf_dfu_settings: Settings OK
    <debug> app: Enter nrf_bootloader_fw_activate
    <info> app: No firmware to activate.
    <debug> app: Enter nrf_dfu_app_is_valid
    <debug> app: Return true. App was valid
    <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
    <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
    <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0
    <debug> app: running irq table set
    <debug> app: After running irq table set

  • I traced down the double reset after a flash program issue. It is actually a deliberate reset by the main app initialization code, due to using the NRF I/O pins as GPIO and not NRF.
    In system_nrf52840.c SystemInit(), line 153 checks to see if the pins are configured as GPIO. If so, it checks, then clears bit 0 of the NFCPINS register (addr 0x1000120c). When a full chip erase is performed, this bit is set by default. Due to this register being a UICR, any modifications are only implemented after a reset. So, this routine forces a chip reset at line 161.
    Since the UICR is non-volatile flash, no subsequent chip power-ups or resets go through the deliberate reset.
Related