Avoid nonit region to be overridden by MCUBoot

RE: Avoid nonit region to be overridden by MCUBoot

colar — Mon, 18 Mar 2024 14:20:44 GMT

Hi,

thanks, that seems to work. When using the device tree as in the retention system the RAM partition is reduced for all images including MCUBoot, so the retention section will then only used by the retention system (it takes the address then from the device tree).

Besides using the retention API it is also possible to just declare a memory section in the device tree and then place variables in there with __attribute__((__section__(".anotherretainedsection"))).

Here is an example device tree overlay for a nRF5340:

/ {
    soc {
        sram0: memory@20000000 {
            compatible = "mmio-sram";
            reg = <0x20000000 0x7e000>;  // reduce SRAM size 
        };

        retentionram: memory@2007f000 {  // new node for the retention RAM
            compatible = "zephyr,memory-region", "mmio-sram";
            reg = <0x2007f000 0x1000>;
            zephyr,memory-region = "RetainedMem";
            status = "okay";

            retainedmem {
                compatible = "zephyr,retained-ram";
                status = "okay";
                #address-cells = <1>;
                #size-cells = <1>;

                /* This creates a 256-byte partition */
                retention0: retention@0 {
                    compatible = "zephyr,retention";
                    status = "okay";
                    reg = <0x0 0x100>;  // adjust this and other partitions as necessary
                    prefix = [08 04];
                    checksum = <1>;
                };
            };
        };

        anotherretainedsection: memory@2007e000 {  // new node for the retention RAM
            compatible = "zephyr,memory-region", "mmio-sram";
            reg = <0x2007e000 0x1000>;
            zephyr,memory-region = "anotherretainedsection";
            status = "okay";
        };
    };

};

Best regards,
Lars

RE: Avoid nonit region to be overridden by MCUBoot

Susheel Nuguru — Thu, 22 Feb 2024 07:51:47 GMT

Colar,

I think it is a bit complicated and untested waters to try to edit MCUboot linker scripts to sync it with application specific mem regions.

But there is this retention system that you try to use. Configuring the DTS seems the biggest part in it but use in the source code seems quite simple.

RE: Avoid nonit region to be overridden by MCUBoot

Susheel Nuguru — Wed, 21 Feb 2024 13:00:34 GMT

[quote user="colar"]I disabled MCUBoot and tested my noinit region - and it works as expected.[/quote]

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.

RE: Avoid nonit region to be overridden by MCUBoot

colar — Wed, 21 Feb 2024 08:29:10 GMT

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?

RE: Avoid nonit region to be overridden by MCUBoot

Susheel Nuguru — Wed, 21 Feb 2024 06:42:19 GMT

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.

RE: Avoid nonit region to be overridden by MCUBoot

colar — Tue, 20 Feb 2024 11:20:34 GMT

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?

RE: Avoid nonit region to be overridden by MCUBoot

Susheel Nuguru — Tue, 20 Feb 2024 11:04:37 GMT

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?