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

Application does not start beside DFU bootloader

Hy everybody,

I'm trying to implement DFU bootloader in our custom board, starting from the "bootloader_secure_example", where I just changed leds and button pins in order to adapt them to our board. I successful flashed the soft device and the bootloader, merged with the bootloader settings, and I can perform a dfu firmware update with the nRF Connect, or nRF Toolbox, BLE app but, after the chip reset, nothing happens! No app advertising nor DFU_Targ. If I manually reset the board, pulling down the proper button, it returns to bootloader mode advertising with the DFU_Targ name. Even if I flash the firmware directly with keyl I see the same behavior.

There are no problems if I use just SD+APP (without bootloader).

I suppose the problem could be something related to rom/ram or bootloader settings.

Here are our settings:

SoftDevice: s13_nrf52_4.0.2
SDK: nRF5_SDK_13.1.0_7ca7556
Chip: nRF52832

Bootloader

IROM1 start: 0x78000
IROM1 size: 0x6000
IRAM1 start: 0x20002060
IRAM1 size: 0xDA70

Application

IROM1 start: 0x1F000
IROM1 size: 0x56000
IRAM1 start: 0x20003800
IRAM1 size: 0xC800

Bootloader settings script

nrfutil settings generate --family NRF52 --application-version 4 --bootloader-version 1 --bl-settings-version 1 bootloader_settings.hex

Bootloader DFU Settings:
* File:                 bootloader_settings.hex
* Family:               nRF52
* CRC:                  0xC90C83B3
* Settings Version:     0x00000001 (1)
* App Version:          0x00000004 (4)
* Bootloader Version:   0x00000001 (1)
* Bank Layout:          0x00000000
* Current Bank:         0x00000000
* Application Size:     0x00000000 (0 bytes)
* Application CRC:      0x00000000
* Bank0 Bank Code:      0x00000001

Merged hex files

mergehex --merge bootloader_settings.hex Bootloader.hex --output Bootloader_with_settings.hex

I tried also to set the variable m_dfu_settings_buffer in the file nrf_dfu_settings.c in this way:

uint8_t  m_dfu_settings_buffer[CODE_PAGE_SIZE] __attribute__((at(BOOTLOADER_SETTINGS_ADDRESS)))
                                                   __attribute__((used)) = {NRF_DFU_BANK_VALID_APP};

but when I try to merge bootloader and bootloader-settings .hex files it returns the error

ERROR: The hex files cannot be merged since there are conflicts.

Any suggestion?

Thanks in advance.

Massimo

Parents
  • You only need to generate the settings page if you plan on flashing the application using a programmer instead of uploading it through the DFU. If you upload the application through the DFU the bootloader automatically creates the settings page.

    Can you try to only flash SD and bootloader, and then upload the application using nRF Connect or similar, and see if that works?

  • The problem is FLASH_STORAGE_ADDRESS in flash_uc.h. This is set to 0x7F000. This is used by the bootloader settings page. I changed it to 0x77000 which is below the bootloader I used, and the application now works.

  • Hi Stian,

    we are migrating from nRF5_SDK_13.1.0_7ca7556 to nRF5_SDK_14.2.0_17b948a.

    Now we have some problems with the bootloader again.

    We can flash the application but then the board remains in bootloader mode, advertising as DfuTarg.

    We also tried to perform a DFU with the same result.

    It seams the bootloader doesn't validate the application. But how can we debug it? If we use the macro NRF_DEBUG_ENABLE the compiler returns a no_space error.

    The only things we changed are:

    1. the SoftDevice requirements (from 0x98 to 0x9D) in the command used to generate the DFU packet;
    2. the macro  NRF_SD_BLE_API_VERSION (from 4 to 5) in the keil option for target.

    Is there any other change we have to do during migration?

    Thanks a lot

    Massimo

Reply
  • Hi Stian,

    we are migrating from nRF5_SDK_13.1.0_7ca7556 to nRF5_SDK_14.2.0_17b948a.

    Now we have some problems with the bootloader again.

    We can flash the application but then the board remains in bootloader mode, advertising as DfuTarg.

    We also tried to perform a DFU with the same result.

    It seams the bootloader doesn't validate the application. But how can we debug it? If we use the macro NRF_DEBUG_ENABLE the compiler returns a no_space error.

    The only things we changed are:

    1. the SoftDevice requirements (from 0x98 to 0x9D) in the command used to generate the DFU packet;
    2. the macro  NRF_SD_BLE_API_VERSION (from 4 to 5) in the keil option for target.

    Is there any other change we have to do during migration?

    Thanks a lot

    Massimo

Children
No Data
Related