What is the right hex file to use to program the device via MCUboot DFU?

[Gus]

Hello:

Looking at the different demos (applications and samples) available for nRF9160, I noticed that some of them generate multiple hex files while others, only few. Most notably, I see videos showing the device programming using MCUboot DFU choosing the app_signed.hex file (asset_tracker and aws_iot), but in other cases such as gps and udp samples, only merged.hex file is generated.

So my question is, which is the right file to use when programming the device via MCUboot DFU (programmer)? When is app_signed.hex generated and when is not?

BTW, I tried to use merged.hex to program the device with the udp or gps sample, and the programmer complains saying the file is not valid. How to program these sample applications then?

I can't find

Thanks

Gus

[Simon]

First I would like to explain how some stuff

When you build an application/sample with CONFIG_BOOTLOADER_MCUBOOT=y in prj.conf, the build system will automatically build the MCUboot sample \ncs\v1.4.0\bootloader\mcuboot\boot\zephyr and the generated MCUboot build output wil get put into <your sample>\<build folder>\mcuboot\zephyr. The mcuboot hex file is the file <your sample>\<build folder>\mcuboot\zephyr\zephyr.hex

The generated build output for your sample/application will get put into <your sample>\<build folder>\zephyr. When CONFIG_BOOTLOADER_MCUBOOT is set, the files described in Using MCUboot in nRF Connect SDK will get generated. It contains both signed and unsigned versions of the application.

Gus said:

but in other cases such as gps and udp samples, only merged.hex file is generated.

So my question is, which is the right file to use when programming the device via MCUboot DFU (programmer)? When is app_signed.hex generated and when is not?

-If you're performing a DFU (loading new image into secondary slot, which MCUBoot validates and swaps with image in primary slot upon reset), the the file app_update.bin should be used.

-If you're programming the chip (using the nRF Connect for Desktop Programmer app or nrfjprog), the file app_update.hex should be used.

-It is important to always use the signed version of the application if using MCUboot and not the unsigned variant <your sample>\<build folder>\zephyr\zephyr.hex, which will cause the validation to fail.

-The files app_signed.hex and app_update.bin are only generated when CONFIG_BOOTLOADER_MCUBOOT=y as mentioned earlier. Try setting CONFIG_BOOTLOADER_MCUBOOT=y in prj.conf.

-The merged.hex file is only generated if the application contains one or several child images and this hex file contains the hex file of the main application as well as the child images. E.g. if CONFIG_BOOTLOADER_MCUBOOT is set, merged.hex will contain the files <your sample>\<build folder>\mcuboot\zephyr\zephyr.hex as well as <your sample>\<build folder>\zephyr\app_signed.hex. If you're building a nonsecure application (nrf9160dk_nrf9160ns) the merged hex file will include <your sample>\<build folder>\spm\zephyr\zephyr.hex also. When you program the merged.hex file, it will program all the mentioned hex files at once.

Gus said:

BTW, I tried to use merged.hex to program the device with the udp or gps sample, and the programmer complains saying the file is not valid. How to program these sample applications then?

I was not able to reproduce this. Are you performing a DFU, or are you flashing the file? If you're doing a DFU, you should use the file app_update.bin. Please tell me and I can give guide you have to go about this.

Best regards,

Simon

[Gus]

Hello Simon:

Thanks for such detailed explanation!

Just to clarify;

>>Are you performing a DFU, or are you flashing the file?

I'm using nRF Connect for Desktop Programmer, so I guess I'm flashing the device. 

So, how can I perform a DFU to program the device?

I guess my confusion comes from this link;

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nc_programmer%2FUG%2Fnrf_connect_programmer%2Fncp_programming_nrf9160dk_intro.html

where it shows how to program the Thingy using the nRF Connect Programmer, but it mentions it is using the MCUBoot DFU... BTW, I see few differences with using the same to program the nRF9160 DK, where it shows similar procedure but then it asks to click Erase & Write button, while for Thingy:91, it only mentions to click Write (all other buttons are disabled).

Thanks

Gus

[Simon]

Aah.. Ok, I understand why you're confused. The Thingy:91 does not come with a built in programmer (like the nRF9160 DK) and you have two options of programming (I'm a but confused myself about the terminology and the difference between programming/flashing. I can see in the documentation they're using "programming" about both DFU-update and flashing, so let's go with "flashing" and "DFU" in this ticket). The two options are:

1. Programming it through USB (DFU/MCUboot) 

Blue: Thingy:91

[Computer-->nRF Connect Programmer] -- USB DFU--> nRF52840 --UART DFU--> nRF9160

Usually the nRF Connect Programmer app is used to flash devices directly, but if you connect the Thing:91 USB directly to the computer, this is not possible. This is because there is not programmer (debug probe) connected. However, the nRF Connect Programmer has the possibility to perform a DFU as well. The way it works is that it sends the image to the USB on the nRF52840 (the Thingy:91 contains both an nRF52840 and an nRF9160) then the nRF52840 has firmware that converts it to UART and sends it to the nRF9160, where it's placed in the secondary flash before being swapped by the MCUBoot on the nRF9160.

By the way, regarding my comments earlier about using the .bin file for DFU. It seems, according to Programming applications through USB (MCUboot), that you have to use the hex file when performing a DFU through the Programmer app. In other instances where you're performing a DFU (at least as far as I'm aware of), the .bin file should be used. E.g. if using the mcumgr tool or downloading the image from nRF Cloud or AWS.

Gus said:

while for Thingy:91, it only mentions to click Write (all other buttons are disabled).

The reason for this is because you can't erase flash through DFU.

2. Programming it through an external debug probe (flashing)

[Computer-->nRF Connect Programmer]  -- USB--> nRF9160 DK Programmer -- SWD--> Thingy:91

If you have an nRF9160 DK, you can flash it directly. This is done by using the programmer on the nRF9160 DK through a 10-pin cable connected to the Thingy:91. This allows you to debug (set breakpoints, watch variables and so on) your application as well, which is an advantage when developing a product.

---

Please check out the video Unbox and get your Nordic Thingy:91 up and running, which I think you will find really helpful.

Best regards,

Simon