flash the SoftDevice, the bootloader, bootloader settings and the application at once

[Roh_Sys]

I am trying to merge Softdevice, bootloader, bootloader setting and application. But unable to do in a single mergehex command. If i do merge seperately ((BL + SD + APP) with Bootloader setting) i am able to merge but after flashing merged file, bootloader starts advertising (as DFU) insted of application.

[Einar Thorsrud]

Hi,

I am trying to merge Softdevice, bootloader, bootloader setting and application. But unable to do in a single mergehex command.

mergehex does not support merging more than three hex files in one instance, but there is no problem splitting it up in two smaller operations. The resulting hex will be the same regardless.

If i do merge seperately ((BL + SD + APP) with Bootloader setting) i am able to merge but after flashing merged file, bootloader starts advertising (as DFU) insted of application.

This should not be related to how the files were merged, as long as you successfully merged all 4 files one way or the other. How did you generate the bootloader settings .hex (what was the full nrfutil command you used)? Can you double-check that it was generated for the exact application hex you are using?

[Roh_Sys]

how to convince the bootloader that the application is valid and start from the application instead DFU ?

[Einar Thorsrud]

Hi,

Roh_Sys said:

how to convince the bootloader that the application is valid and start from the application instead DFU ?

The bootloader will start the application if it is valid and match the CRC in bootloader settings, and there is no other indication that it should enter DFU mode (GPIO pin, GPREGRET etc.). So based on what you have provided, the bootloader should have started the application. There are some pitfalls, though.

First of all, you can often see the problem if you test with a debug bootloader with RTT logging. Alternatively, you could look at the most typical pitfalls as described below.

CRC mismatch:

• You should make sure to use the exact same app.hex with nrfutil settings generate as you use in the merged hex. Any difference will cause the CRC check to fail and the bootloader will enter DFU mode instead of starting the application.
• You should make sure that the application does not write to flash in the region in which the CRC is calculated over, and this is from the first byte of the application until the last byte. If you, for instance, put some data at a fixed memory location separated from the application this means that also any empty space in between is considered part of the application region when it comes to the CRC. So any flash writes in between will cause the CRC to fail.

A simple way to check if one of the above is the problem is to configure the bootloader to not do CRC validation on startup. To do so, modify app_is_valid() in <SDK>\components\libraries\bootloader\nrf_bootloader.c to always return true. Make sure to flash the modified bootloader to the board. Is the application started in this case?

DFU mode signaled by GPIO pin:

• NRF_BL_DFU_ENTER_METHOD_BUTTON is set to 1 in sdk_config.h, but the state of the pin configured with NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN is either floating or asserted.

Could this be the case?