Using BLE OTA DFU to update the Bootloader itself

Question

Hi, 
 
 We develop in an OpenSuse VM so that we all have the benefit of only having to setup the tools once. Segger Embedded Studio was building our variant of the DFU Bootloader example. We use the debug version of the project since we have security key checking turned off for the time being. When we use a Jlink and SES to program one of our target boards containing the nrf52833 the target programs correctly and we get an MBR, SoftDevice S113, a bootloader, and and MBR parameters page and Bootloader Settings page that all seem to work together. However, when we try to package up the bootloader app and generated bootloader settings page, with a small update, just the advertising name to show that the update worked, the OTA DFU (using nrf connect on an android phone to send the .zip file) the update appears to work, but the new advertising name does not show up, until I erase the chip and use SES to update the target hardware. I have attached a link to our zipped repo of the modified DFU example. The modified DFU example code is here: https://drive.google.com/file/d/1AynGuAxH_khmbu_RpCUoxpiVGjGaK0PB/view?usp=sharing We had to change the BOOTLOADER_START_ADDR to be 0x71000 instead of the 0x78000 used in the original SDK example because we compiled in uECC for the security library. I changed this in the project options section placement macros in SES to FLASH_START=0x71000. Do I need to change that somewhere else as well? The reason I ask is that location 0x0FF8 and NRF_UICR->NRFFW[0] the shows different addresses when I look at the flash I read out with the Jlink after programming through SES and the generated hex file in the output/exe folder. In our repo we have a script IsaacPackageDfuForDFU to package the bootloader hex and settings hex into a .zip file for OTA DFU using an android phone. The relevant lines are: nrfutil settings generate --family NRF52 --application $DFU_DBG_EXE --application-version 0 --bootloader-version 2 --bl-settings-version 2 $DFU_DBG_SETTINGS_FILE 
 In_The_Field Production_Unit_Readback.hex Actall_HDT_NG_Bootloader_S113_Debug.hex mergehex -m $DFU_DBG_SETTINGS_FILE $DFU_DBG_EXE -o merged.hex nrfutil pkg generate --debug-mode --hw-version 52 --application-version 0 --application merged.hex $DFU_DBG_APP_FILE After I package the bootloader and attempt to update it OTA, it seems like the DFU update took, but rebooting the hardware does not cause advertising, not with the advertising name NRF_DFU_BLE_ADV_NAME "DfuTarg" of the original image that was in the hardware or with the updated NRF_DFU_BLE_ADV_NAME of "Actall_Temporary". Do I need to be packaging up a MBR settings page as well? If I did that would it even help since the bootloader start address has been modified and there is a hard coded address inside the MBR code that is packaged with the softdevice? Our issue is that we have a thousand units in the field with just the bootloader and no app in them. We can add the app once, but then we can never update it again because the DFU will always jump to the app after that. So we want to update the custom bootloader we put in there to our new custom bootloader that will jump to DFU if a button is held down at boot. We can make this work when programmed with a J-link, but we can't do it over the air which means we would need to open the cases of the 1000 units in the field that contain just the bootloader and use a Jlink and a cable to update the bootloader. I have attached a hex file of the image we have in units in the field which only allow us to update the application once as well as the hex being generated by SES for the improved hold-the-button-on-boot-to-DFU version of the bootloader Actall_HDT_NG_Bootloader_S113_Debug.hex. If it helps, I can give you access to the whole linux dev environment virtual machine, although it is 14 GB to download. Any hints as to what I may be doing wrong?

Sigurd · Accepted Answer

Hi, 
 I have attached a link to our zipped repo of the modified DFU example. The modified DFU example code is here: 
 Looking at your code, you seem to have changed NRF_DFU_REQUIRE_SIGNED_APP_UPDATES from default 1, to 0, this means that Application update may come from an unsigned package. Bootloader update must come from signed packages. 
 
 idavenport said: Is the private key available for experimentation with the default example? 
 As far as I can see, this key is not provided. 
 
 Our issue is that we have a thousand units in the field with just the bootloader and no app in them. We can add the app once, but then we can never update it again because the DFU will always jump to the app after that. 
 How does the bootloader's sdk_config.h file look like for the devices you have in field? You might not need to update the bootloader to do this. You seem to have NRF_BL_DFU_ENTER_METHOD_BUTTON set to 1, with button 8 being used to enter DFU mode. Snippet: 
 
#ifndef NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN
// Original pin for the dev kit:
// #define NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN 25
//
// This is the 'PANIC' switch on HDT_NG, P0.08. It is active low when button
// pressed.
//
// We have not implemented the full-on multi-platform support here as we did
// in the HDT_NG code.
#define NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN 8
#else
#warning "NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN already defined!"
#endif 
 So that is one method. 
 You also have: 
 // <q> NRF_BL_DFU_ENTER_METHOD_GPREGRET - Enter DFU mode when bit 0 is set in the NRF_POWER_GPREGRET register.
#ifndef NRF_BL_DFU_ENTER_METHOD_GPREGRET
#define NRF_BL_DFU_ENTER_METHOD_GPREGRET 1
#endif 
 So you can call this in the application code: uint32_t err_code;

err_code = sd_power_gpregret_clr(0, 0xffffffff);
 APP_ERROR_CHECK(err_code);

err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
 APP_ERROR_CHECK(err_code); 
 And call sd_nvic_SystemReset(), and on reset it will then enter DFU mode. This is the same mechanism that the Butonless DFU service uses.

Using BLE OTA DFU to update the Bootloader itself

Top Replies