This is a strange problem and I do hope I am missing something. There are two bootloaders in the examples/dfu section for a particular transport - with debug and without debug. Making my own custom build of the bootloader for the project (private key, buttonless, no uart, etc), I stumbled upon an unexplainable for me problem: The same bootloader, with the same code works properly when the debug information is included and hangs silently when not.
Things that are different between the two:
A few nuts and bolts concerning RTT logging configuration (same as in the example code provided) and LOG_LEVEL settings.
The one without debug omits a pair of the debug related macros - DEBUG_NRF and NRF_DFU_DEBUG_VERSION
Flash placement differs: The one with debug takes flash from x71000, the one without debug from x78000 (as in examples), RAM placement is the same for both.
Flash sections order is a tiny bit different, but that doesn't look like critical problem, there is no 4x4 overlaps in the final image and Programmer verifies it as correct.
Everything else, as far I managed to check, is the same. What am I missing?
Does anybody else meet with this situation?
Could you check which version of mergehex you have ? We had an issue with v10.12.1 , you can have a look here: https://devzone.nordicsemi.com/f/nordic-q-a/75729/possible-mergehex-issue-v10…
The bug with mergehex was the one, as I wrote above :) and I tested it as soon as 10.12.2 came out, on saturday morning - It works ok, the gap mishandling and alignment issue was fixed in 10.12.2. I was just waiting for your notification to confirm. One of the misfortunes of that bug was damaging the boundary areas between text and rodata, and between rodata and application sections (and THAT is where all the observers addresses are collected!).
As for the changing of bootloaders with different start address - yes, thank you, I just forgot about the MBR/UICR bootloader start address thing :) Of course, you can't (safely) change these things on the fly, you must stick to one address and I do remember that it was written somewhere in the docs, but that warning was a bit vague, as it was talking about sizes, not addresses.