This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Create a single, working .hex file from application + bootloader + S132 + nrf_dfu_settings_t

We've had so many problem with Bluetooth Smart DFU on nRF52832 that I've decided to write a ticket here and ask for help. We've been reading lots of documentation, following articles and examples, but getting DFU working have been a mess. We have finally been able to do DFU, so now we want to generate a script that uses the compiled bootloader.hex and application.hex to create a fully working hex file ready to be flashed, that is, after flashing the chip shall boot up and run the application as if there is no bootloader, from the very first reset.

We've finally found out that in order to do this, we must merge bootloader.hex, application.hex, nRF52_SDK_16.0.0/components/softdevice/s132/hex/s132_nrf52_7.0.1_softdevice.hex and a generated application_dfu_settings.hex. Using mergehex as suggested did not work, it can only merge 3 hex files, and if we merge two times (3 + 1) the hex will not run if flashed and it is impossible to debug why (I guess it does not place the text properly).

Luckily, we found the very nice nRF Connect Programmer program which lets us add the 4 hex files visually. And it lets us flash the chip and read back the content visually (it looks correct too). And finally the program lets us save the result as a hex file. It turns out that if we flash the chip with this hex file, everything works exactly as we want. Magic.

How do I merge the 4 hex files into 1 hex file from command line exactly as nRF Connect Programmer does? Because we need a script to automatize the process.

We use nRF52 SDK 16.0.0 and Segger Embedded Studio.



PS: The SDK also contains a hex file components/softdevice/mbr/hex/mbr_nrf52_2.4.1_mbr.hex. We did not use that. It seems that nRF Connect Programmer adds a MBR automatically when adding s132_nrf52_7.0.1_softdevice.hex. What is mbr_nrf52_2.4.1_mbr.hex for?

PPS: Our bootloader does actually not work as expected. Instead we had to remove the nrf_bootloader_flash_protect() code before nrf_bootloader_init(), otherwise it hangs in an unknown state.

Parents
  • Hello.

    I am sorry to hear that you ran into a lot of issues regarding the bootloader and DFU part.

    It is true that you can't merge 4 files. I usually do 2+2, and then merge those into one, but 3+1 should be just as good. 

     

    PS: The SDK also contains a hex file components/softdevice/mbr/hex/mbr_nrf52_2.4.1_mbr.hex. We did not use that. It seems that nRF Connect Programmer adds a MBR automatically when adding s132_nrf52_7.0.1_softdevice.hex. What is mbr_nrf52_2.4.1_mbr.hex for?

     If you use the softdevice, you don't need the MBR. MBR is already included in the softdevice.

    FYI MBR is the part that shuffles the images around after a DFU.

     

    PPS: Our bootloader does actually not work as expected. Instead we had to remove the nrf_bootloader_flash_protect() code before nrf_bootloader_init(), otherwise it hangs in an unknown state.

     That doesn't sound good. Have you tried to use the _debug project and try to figure out why nrf_bootloader_flash_protect() doesn't return? If you use the _debug project you can turn off optimization and enable logging, since the space for the bootloader is increased.

    So to your original question:

    I assume the 4 hex files you are talking about is Bootloader (BL), Softdevice (SD), Application (APP) and Bootloader Settings (BS), is that correct?

    Does it run properly if you manually program these using e.g. nrfjprog?

    When it doesn't work (when using the merged hex file), what is the behavior of the device? Do you have any indications on whether it is starting the application? Or if it is stuck in DFU mode? Does it advertise?

    What HW are you doing these tests on? Is it an nRF52832 DK? 

    PS: When you program the merged hex file, how do you do that? Did you remember to reset the device afterwards?

    mergehex -m BL.hex SD.hex -o temp1.hex
    mergehex -m BS.hex APP.hex -o temp2.hex
    mergehex -m temp1.hex temp2.hex -o merged_file.hex
    
    nrfjprog -e
    nrfjprog --program merged_file.hex --verify
    nrfjprog --reset

    BR,

    Edvin

Reply
  • Hello.

    I am sorry to hear that you ran into a lot of issues regarding the bootloader and DFU part.

    It is true that you can't merge 4 files. I usually do 2+2, and then merge those into one, but 3+1 should be just as good. 

     

    PS: The SDK also contains a hex file components/softdevice/mbr/hex/mbr_nrf52_2.4.1_mbr.hex. We did not use that. It seems that nRF Connect Programmer adds a MBR automatically when adding s132_nrf52_7.0.1_softdevice.hex. What is mbr_nrf52_2.4.1_mbr.hex for?

     If you use the softdevice, you don't need the MBR. MBR is already included in the softdevice.

    FYI MBR is the part that shuffles the images around after a DFU.

     

    PPS: Our bootloader does actually not work as expected. Instead we had to remove the nrf_bootloader_flash_protect() code before nrf_bootloader_init(), otherwise it hangs in an unknown state.

     That doesn't sound good. Have you tried to use the _debug project and try to figure out why nrf_bootloader_flash_protect() doesn't return? If you use the _debug project you can turn off optimization and enable logging, since the space for the bootloader is increased.

    So to your original question:

    I assume the 4 hex files you are talking about is Bootloader (BL), Softdevice (SD), Application (APP) and Bootloader Settings (BS), is that correct?

    Does it run properly if you manually program these using e.g. nrfjprog?

    When it doesn't work (when using the merged hex file), what is the behavior of the device? Do you have any indications on whether it is starting the application? Or if it is stuck in DFU mode? Does it advertise?

    What HW are you doing these tests on? Is it an nRF52832 DK? 

    PS: When you program the merged hex file, how do you do that? Did you remember to reset the device afterwards?

    mergehex -m BL.hex SD.hex -o temp1.hex
    mergehex -m BS.hex APP.hex -o temp2.hex
    mergehex -m temp1.hex temp2.hex -o merged_file.hex
    
    nrfjprog -e
    nrfjprog --program merged_file.hex --verify
    nrfjprog --reset

    BR,

    Edvin

Children
  • Sorry for a late reply. We have been busy.

    We have been doing our development on a custom board.

    Yes, these are the 4 hex files. Does the mergehex tool do special considerations and rearrangements in order to merge the parts correctly or is it just very simple? It seems that the nRF Connect Programmer analyses the given hex files (it knows for example which the SoftDevice is), but does it then do anything more advanced than mergehex?

    Thanks!

  • speedycat said:
    but does it then do anything more advanced than mergehex?

     No. It is basically the same. Mergehex and nrf connect will just merge all the data in the files. They will also warn you if there are any overlaps/conflicts in the files that you are merging. 

    The reason that nRF Connect says "Softdevice" or "application" is just because it knows where those are supposed to be, and what they look like. It isn't perfect, but it is an "estimate". 

Related