Files for OTA firmware update stored in flash

RE: Files for OTA firmware update stored in flash

Pierre cgwi22 — Tue, 04 Feb 2020 16:18:00 GMT

Thanks a lot! It works now and we have succesfully swapped on the new firmware.

But it takes about 2 minutes between the reboot in DFU mode and the start of the new firmware. Is this delay normal? (For information the firmware has a size of 213140 bytes)

RE: Files for OTA firmware update stored in flash

Einar Thorsrud — Tue, 04 Feb 2020 14:42:20 GMT

Hi,

Good point. The background is that backup of bootloader settings was introduced as a security feature, as part of the support for secure boot. You can disable parts of this check by setting NRF_DFU_SETTINGS_ALLOW_UPDATE_FROM_APP to 1 in the bootloaders sdk_config.h. Alternatively, you can remove it altogether by modifying settings_forbidden_parts_equal_to_backup in <SDK>\components\libraries\bootloader\dfu\nrf_dfu_settings.c to always return true.

I am sorry I did not mention this before. (In my faulty memory settings backup was introduced in SDK 15.3 rather than 15.2).

RE: Files for OTA firmware update stored in flash

Pierre cgwi22 — Tue, 04 Feb 2020 11:03:28 GMT

Perhaps our problem comes from the settings backup in 0xFE000 which is not the same as our settings in 0xFF000, so the settings are overwritten like in this thread.

So we need to write the same data in 0xFE000 and 0xFF000 but the 0xFE000 page is protected by the bootloader like explained in this other thread. Is there a solution for removing this protection directly from the application, without modifying the bootloader?

RE: Files for OTA firmware update stored in flash

Pierre cgwi22 — Mon, 03 Feb 2020 18:27:46 GMT

Concerning our last question in the previous post, we have found a difference between the online documentation and the bootloader code about the CRC.

In the description of the settings structure, we can read "uint32_t nrf_dfu_settings_t::crc CRC for the stored DFU settings, not including the CRC itself."

But in the comments of the bootloader code, for the settings_crc_get() function, it is written "The crc is calculated from the s_dfu_settings struct, except the crc itself and the init command"

So we have removed the init command from the CRC calculation but the behavior stays the same.

RE: Files for OTA firmware update stored in flash

Pierre cgwi22 — Mon, 03 Feb 2020 16:20:47 GMT

OK, thanks!

We have checked what the bootloader do in nrf_bootloader_init() and nrf_bootloader_fw_activate(). It seems ok compared to our settings, but perhaps the problem appears above, in nrf_dfu_settings_init().

Here is our full nrf_dfu_settings_t structure values after adding the init command:

crc = computed value of the settings, like the documentation explains
settings_version, app_version and bootloader_version = no modification
bank_layout and bank_current = no modification
bank_0:
- image_size and image_crc = no modification
- bank_code = NRF_DFU_BANK_INVALID
bank_1:
- image_size = size of the new firmware
- image_crc = computed value of the new firmware
- bank_code = NRF_DFU_BANK_VALID_APP
write_offset and sd_size = no modification
progress:
- command_size = size of the init command
- command_offset = no modification
- command_crc = computed value of the init command
- data_object_size = no modification
- update_start_address = bank 1 address
enter_buttonless_dfu = 1
init_command = init command data

Is it correct? About the CRC of the settings, we must include all the size of the init_command table (256 bytes with several 0xFF at the end) or only the size of the written data?

RE: Files for OTA firmware update stored in flash

Einar Thorsrud — Mon, 03 Feb 2020 13:13:45 GMT

Hi Pierre,

I am sorry, I did not mention that you need to populate bank_1 in the bootloader settings. The bank_code field must be NRF_DFU_BANK_VALID_APP. The bootloader checks this during startup (nrf_bootloader_init() calls nrf_bootloader_fw_activate()), and will continue with activation if the code is NRF_DFU_BANK_VALID_APP.

Br,

Einar

RE: Files for OTA firmware update stored in flash

Pierre cgwi22 — Sat, 01 Feb 2020 16:09:11 GMT

Currently the application code starts in memory at address 0x26000 and finishes at 0x58DD1. So the new firmware data (.bin) is stored in the following page at 0x59000.

The bootloader settings are stored on the last page, at 0xFF000. We have written the init command (.dat) in the nrf_dfu_settings_t structure and calculated the CRCs. Then the modified settings are rewritten in flash.

Finally, we have tried to reboot on DFU mode with the following 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);
nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);

Is it the good way to do what we want? This is not working, the bootloader seems doing nothing during 2 minutes then it reboots on the original application and the settings are reinitialized in flash.

RE: Files for OTA firmware update stored in flash

Einar Thorsrud — Thu, 30 Jan 2020 13:02:11 GMT

Hi,

The image (.dat) should be located in bank 1, which is calculated by nrf_dfu_bank1_start_addr(). The init command should be stored in the bootloader settings page (nrf_dfu_settings_t::init_command). Note that this approach described by Vidar describes how you can use the "normal" SDK bootloader to do DFU from the application. This makes a lot of sense in many cases, for instance, if you also want BLE transport in the bootloader, or you need a well-tested solution.

(If you only intend to do DFU via your modem, then another approach could be to use a thin bootloader such as the IoT backround DFU library (this uses many of the same concepts). However, there is no complete example for the IoT DFU solution, and it is experimental.)

RE: Files for OTA firmware update stored in flash

Pierre cgwi22 — Thu, 30 Jan 2020 10:55:30 GMT

Thanks for your help.

In fact we can't use the DFU transport because the new firmware come from an external FTP server, downloaded in several parts and with some extra data we need to filter. We can't modify this behavior. It's the reason why we have created our own storage method in flash memory.

So we must just know how we can inform the bootloader about the addresses of the .bin and .dat data in the flash to be able to perform the swap.

RE: Files for OTA firmware update stored in flash

Einar Thorsrud — Thu, 30 Jan 2020 10:20:26 GMT

Hi,

[quote user=""]We have tried to store firstly all the .zip DFU file in flash, but according to this answer on an other thread we can't do that.[/quote]

You should not store the . zip on the nRF (then you would have to have flash to unzip it etc).

[quote user=""]Can you explain which files must be used and where in the flash memory ?[/quote]

You should transfer and store the raw binary image (.bin) file as well as the init packet (.dat file). You do not actually have to think about how this is stored. Instead, you can make a transport for your cellular modem similar to the UART transport as described here. Then the DFU library will temporarily store the data for you (somewhere between the application end address and the reserved application data pages).

I recomend you refer to the project Vidar posted in the thread you linked to as an example of how this can be done. Note that it uses some support that was introduced in SDK 15.3, which is the first SDK with proper support for DFU in the application. If you start playing with that, which is a working example, then you can adapt that to your cellular transport starting off with a known good base. Once that works, you can port it to your application.