mergehex error: "Overlapping segments detected at address 0.ERROR: The hex files cannot be merged since there are conflicts.

[Snakehater]

Hello

I just downloaded nrf sdk 12.3 and am facing a problem straight away where I couldn't find valid answers that would fix my problems when searching this forum and on google. The error I get when trying to merge s130 softdevice and ble_app_uart_pcal10028_s130.hex before flashing. The application is straight from the hex folder in nRF5_SDK_12.3.0/examples/ble_peripheral/ble_app_uart/. I have a nrf51802 board which I have read should be almost identical to nrf51822 but with worse tolerances etc since it's a budget version. I don't have a name for my board where my chip sits, it looks like this and have worked before with other code, just not my code: 

The script I use is as follows:

export SOFTDEVICE_NAME=s130_softdevice/s130nrf51_201.hex
export APP_NAME=_build/main.hex
export MERGE_NAME=_build/merge.hex


echo Export has been done!
mergehex -m $SOFTDEVICE_NAME $APP_NAME -o $MERGE_NAME
nrfjprog --recover -f NRF51
nrfjprog --program $MERGE_NAME --verify --chiperase -f NRF51
nrfjprog --rbp ALL -f NRF51
nrfjprog -r -f NRF51

This gets executed at root of the repo where also nRf51_SDK_12.3.0 folder. The main.hex in _build is from ble_app_uart_pca10028_s130.hex.

I flash with j-link segger. 

OS: Debian GNU/Linux

How can I resolve this issue to proceed with my flashing?

[Einar Thorsrud]

Hi,

The issue you describe here is only about merging, so we can ignore everything related to the IC, J-Link etc. The issue must be one of two:

1. the two hex files actually overlap, or
2. the mergehex tool has a bug which makes it think the hex files overlap

Of the two, alternative 1 seems most likely so you should check that first. What is the start and end address of the two hex files? You can for instance use nRF Connect Programmer to easily check. Do they overlap? If so, you need to check why. The SoftDevice is easy, as the documentation states that the size is 0x1B000 bytes, so the end address should be below that number. The application should start at exactly 0x1B000, as it always starts immediately after the SoftDevice. Does the application hex start lower? If so, you need to adjust the start address. (The example project files in SDK 12.3 has the correct start address, but perhaps you modified it?)

I would only consider alternative 2 after ruling out alternative 1, and if that turns out to be the problem, I would start by updating to the latest nRF Command Line Tools and then look deeper if it still fails.

[Snakehater]

Found my solution, I used the premade binary that probably already had a softdevice merged. Building the program again gives me a file that starts att the required address and could now be merged and flashed.

[Einar Thorsrud]

Good to hear. Yes, all pre-built application hex files that depends on a SoftDevice includes both the application and the SoftDevice it depends on.