Avoid nonit region to be overridden by MCUBoot

[colar]

Hi,

I'm using the nRF Connect SDK 2.5.1 with the nRF5340 and MCUBoot as bootloader. I want to store some information about the reboot reason (and some other stuff) in the noinit region to save it across a restart. I placed the variables in the noinit region like this:

static __noinit volatile unsigned int reset_reason;

But on the next boot my whole noinit region is set to 0xFF. I think this comes from MCUBoot as in the map files I can see the noinit region of my application overlaps with the mock_flash region of the flash simulator from MCUBoot (which is needed to transfer the image to the network core afaik). The answer here does not provide a soultion for that, even though the question seems similar.

build/mcuboot/zephyr/zephyr.map:

 .bss.mock_flash
                0x00000000200060da    0x40000 zephyr/drivers/flash/libdrivers__flash.a(flash_simulator.c.obj)

build/zephyr/zephyr.map:

noinit          0x000000002001af70    0x13888
 *(SORT_BY_ALIGNMENT(.noinit))
 *(SORT_BY_ALIGNMENT(.noinit.*))
...

What is the proper way to keep my noinit section? Please give an example if possible.

Best regards,
Lars

[Susheel Nuguru]

Seems to work for most, I have used different __attribute__ when using Segger but I think it is different with different compiler.

Do you think the volatile keyword might be causing this?

[colar]

No, the volatile keyword does not change it.

I think it comes from the placement of the sections noinit in my app and mock_flash the bootloader. When the device restarts, the bootloader overrides the whole noinit section of my app as mock_flash is the RAM section used by the flash simulator used by MCUBoot.

So I should probably make sure the noinit region is not used by any RAM section of MCUBoot - but how?

[Susheel Nuguru]

Hmm, it is possible that MCUBoot is messing with your configuration in the app. But before we can look into the MCUBoot side, can you see if the method mentioned in this thread any different results.

[colar]

This is precisely the thread I referenced in my initial question. However, I'm struggling to see how the answer is relevant to my situation, as it pertains to retaining RAM in the "system off" state for the nRF52 series. This state should not be reached during a software reset, such as a hard fault, which I am using for testing. Moreover, if retention were the issue, I would expect to see all zeros in the memory, not 0xFF everywhere. They mention specifying a noinit region, which I have also done.

To make sure MCUBoot is the problem, I disabled MCUBoot and tested my noinit region - and it works as expected. So my initial question remains: How do I make sure the noinit region does not overlap with memory sections from my bootloader? Linker script, partition manager?

[Susheel Nuguru]

colar said:

I disabled MCUBoot and tested my noinit region - and it works as expected.

OK, I did not get to the point until now that MCUBoot is the actual cause.This topic seems to have been discussed here without any clear specific instructions to edit MCUBoot  linker script. 

I have asked the MCUBoot expert to help me point out to configuration settings to tell the bootloader not to touch the application specific noinit configuration. This might not be that straight forward.