Mergehex: Overlapping segments detected at address 4096

[Jur]

Hi! Thanks for reading this post. I'm having an issue creating a firmware package for our manufacturer. I'm using a nRF52832 with SDK version 15.3.0_59ac345. Whenever I merge try to merge everything together I am getting an error indicating that segments are overlapping. I can however not figure out how this happened and why.

This is how I merge everything together:


mergehex --merge ./Bootloader/Bootloader.hex _build/App.hex ./Bootloader/Settings.hex --output _build/App_BL_Merge.hex
Parsing input files.
Merging file "Bootloader.hex" into output.
Merging file "App.hex" into output.
Merging file "Settings.hex" into output.
Storing merged file.
mergehex --merge _build/App_BL_Merge.hex Libraries/nRF5_SDK_15.3.0_59ac345/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex --output _build/Full_firmware.hex
Parsing input files.
Merging file "App_BL_Merge.hex" into output.
Merging file "s132_nrf52_6.1.1_softdevice.hex" into output.
Overlapping segments detected at address 4096.ERROR: The hex files cannot be merged since there are conflicts.

This is what the memory segment of my linker script looks like:
MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x52000
  RAM (rwx) :  ORIGIN = 0x20002AA8, LENGTH = 0xD558
}

I looked at the "App_BL_Merge.hex" to see if I could find the issue. Only the Softdevice is missing in this file, and if I understand correctly it will be placed between the application and the MBR, it looks like there should be enough space there:

Just in case I tried to increase the FLASH start location to up to 0x30000 to ensure there is enough space for the softdevice, this doesn't make a difference though.
Could anyone tell me what is overlapping, why, and how to fix it? Thanks a lot

[Jur]

After some more Googling I figured 0x00000FF8 is the location of UICR. I was able to merge the file and flash it like this:

# Erase chip
nrfjprog -f NRF52 -e

# Merge softdevice and bootloader
mergehex -m ./Libraries/nRF5_SDK_15.3.0_59ac345/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex ./Bootloader/Bootloader.hex -o _build/Merged_BL_SD.hex

# Generate bootloader settings
nrfutil settings generate --family NRF52 --application _build/App.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 _build/App_BLs.hex

# Merge app and bootloader settings with softdevice + bootloader
mergehex -m _build/Merged_BL_SD.hex _build/App.hex  _build/App_BLs.hex -o _build/Full_firmware.hex

# Write to chip
nrfjprog -f NRF52 --program _build/Full_firmware.hex
nrfjprog -f NRF52 --reset

The firmware works as expected, however when trying to view this "Full_firmware.hex" in nRF connect I am still getting the following error:

[Vidar Berg]

Hello,

From  SDK 15.3.0 and later, we started to store the bootloader start and MBR params page address at 0xff8 and 0xffc inside the MBR region. We used UICR registers for this previously (address 0x10001014 and 0x10001018), but we changed to using the addresses in the MBR as an extra security measure because the UICR register could not be protected with BPROT/ACL. Anyway. This does not explain the merge conflict. What version of mergehex.exe are you using (mergehex --version)?

[Jur]

Hi Vidar! Thanks for your reply. Im using: mergehex version: 10.12.1. I'm starting to think the output of nRF Connect (in my second update) gives a better explanation of what is going wrong.

[Vidar Berg]

Hi,

Please try with version 10.12.2. It was just released and includes a fix for mergehex.

https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Command-Line-Tools/Download#infotabs

[Jur]

Hi, that sounds really promising. I'm running Linux however and the link https://www.nordicsemi.com/-/media/Software-and-other-downloads/Desktop-software/nRF-command-line-tools/sw/Versions-10-x-x/10-12-2/nRF-Command-Line-Tools_10_12_2_Linux-amd64.zip 404's for me.

[Vidar Berg]

Sorry about that. Download does not work for any of the new variants it seems. I'm looking into it now.

Edit: you may try version 10.11.x while I try to figure this out. The merghex bug is only present in version 10.12.0-2