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.hexActall_HDT_NG_Bootloader_S113_Debug.hexmergehex -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?
