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

nRF Connect Desktop - Programmer - Unexpected memory regions after DFU

Hello,

I am working on the Nordic DFU to develop a bootloader for OTA update on our product.

So far I just ported the Secure Bootloader from Nordic examples. No functionality has been changed.

Testing the DFU with different security settings and checking final memory layout.

One thing I did is creating a special target for the bootloader to be placed in a slightly bigger memory area, so that I can enable debug logging via RTT:

from 0x6E000 to 0x7E000, so I'm reserving 64kB.
I did not see any functional problem so far, but looking at memory layout with Programmer app before and after DFU, I've seen something rather odd:
Before
After
As you can see, aside from the new application, 3 new regions (1 page each) appeared just before Bootloader.
After investigating the HEX file, they are all 8 bytes long containing exactly the same sequence.
Exactly the same thing is happening for the Bootloader "Release", contained in 24kB and living at the default address (0x78000).
I honestly did not find anywhere in the code something related to this, how could this happen in your opinion?
It is suspicious that they map with the area that BL reserves for App Data (NRF_DFU_APP_DATA_AREA_SIZE), which is set to 3 pages... but Bootloader should not write into it.
Any clue about what's going on? Also MBR params and BL settings slightly changed their layout in the second image...but at least the starting point is what I expected.
So far I just performed Application DFUs.
I could be that either I don't understand how this Programmer App works, or I'm missing something quite fundamental.
I also thought that something in the application could write there immediately at boot (Peer Manager? But I'm not using bonds...). Any clue on your side could be helpful.
Thanks,

D
Related