Dear NRF community and support
This is a followup question to the DevZone post https://devzone.nordicsemi.com/f/nordic-q-a/2860/flashing-bootloader-and-application-via-j-link, which does not seem to be valid anymore or seems to have side-effects.
I am currently developing a new product with a NRF52 and I'd like to ask kindly for some guidance.
We would like to flash the Bootloader and Application at the same time via J-Link, so we have a faster production pipeline and a product ready for use.
The solution would be to initialise the BOOTLOADER_SETTINGS as seen in nrf_dfu_settings.c, so the Bootloader recognises and boots the accompanying Application flashed via J-Link (no OTA).
Looking at the file nrf_dfu_types.h, the settings page format is as follows:
typedef struct
{
uint32_t crc; /**< CRC for the stored DFU settings, not including the CRC itself. If 0xFFFFFFF, the CRC has never been calculated. */
uint32_t settings_version; /**< Version of the current DFU settings struct layout. */
uint32_t app_version; /**< Version of the last stored application. */
uint32_t bootloader_version; /**< Version of the last stored bootloader. */
uint32_t bank_layout; /**< Bank layout: single bank or dual bank. This value can change. */
uint32_t bank_current; /**< The bank that is currently used. */
nrf_dfu_bank_t bank_0; /**< Bank 0. */
nrf_dfu_bank_t bank_1; /**< Bank 1. */
uint32_t write_offset; /**< Write offset for the current operation. */
uint32_t sd_size; /**< Size of the SoftDevice. */
dfu_progress_t progress; /**< Current DFU progress. */
uint32_t enter_buttonless_dfu;
uint8_t init_command[INIT_COMMAND_MAX_SIZE]; /**< Buffer for storing the init command. */
uint32_t boot_validation_crc;
boot_validation_t boot_validation_softdevice;
boot_validation_t boot_validation_app;
boot_validation_t boot_validation_bootloader;
nrf_dfu_peer_data_t peer_data; /**< Not included in calculated CRC. */
nrf_dfu_adv_name_t adv_name; /**< Not included in calculated CRC. */
} nrf_dfu_settings_t;
The mentioned solution in the DevZone post (https://devzone.nordicsemi.com/f/nordic-q-a/2860/flashing-bootloader-and-application-via-j-link) setting the whole BOOTLOADER_SETTINGS to NRF_DFU_BANK_VALID_APP (0x01) seems to me quite risky, as all other fields in the BOOTLOADER_SETTINGS will be set to 0x01 as well. And there is no guarantee for it to be working if we do an OTA of a new Bootloader image.
So there has to be a more elegant solution:
- Writing the BOOTLOADER_SETTINGS on the very first boot up (all 0xffff) to a valid state, by checking the BOOTLOADER_SETTINGS section and assuming a valid application to be present.
- Writing the BOOTLOADER_SETTINGS manually using a dummy project, linker script or Segger flashing script. This is probably the way I would go, as I do not have to touch and manipulate the SDK, and can create a .hex file just for the BOOTLOADER_SETTINGS section.
What does NRF suggest its industrial customers?
Best regards
Markus Wegmann
Technokrat GmbH
