[MCU BOOT] `RAM' overflowed

[MartKano]

Hello, 

I'm trying to implement the MCU BOOT in order to introduce the Firmware uptdate but I get the following error: 

c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: zephyr\zephyr_pre0.elf section `bss' will not fit in region `RAM'
c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: region `RAM' overflowed by 246080 bytes
collect2.exe: error: ld returned 1 exit status

I'm trying to reduce the RAM usage but with no succes.

When I build my program without the MCU BOOT I get this following build report: 

[0/418] Performing build step for 'tfm'
ninja: warning: premature end of file; recovering
[8/18] Linking C executable zephyr\zephyr_pre0.elf

[11/18] Linking C executable zephyr\zephyr_pre1.elf

[16/18] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      186748 B       256 KB     71.24%
             RAM:       51044 B        64 KB     77.89%
           SRAM1:          0 GB        64 KB      0.00%
        IDT_LIST:          0 GB         2 KB      0.00%

[401/414] Linking CXX executable zephyr\zephyr_pre0.elf

[405/414] Linking CXX executable zephyr\zephyr_pre1.elf

[411/414] Linking CXX executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      240064 B       992 KB     23.63%
             RAM:       96280 B       416 KB     22.60%
        IDT_LIST:          0 GB         2 KB      0.00%

In my _cpuapp_common.dts

/ {

	reserved-memory {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		sram0_image: image@20000000 {
			/* Zephyr image(s) memory */
		};

		sram0_s: image_s@20000000 {
			/* Secure image memory */
		};

		sram0_ns: image_ns@20040000 {
			/* Non-Secure image memory */
		};
	};
};

In my cpuapp_partition_conf.dts : 

&slot0_partition {
	reg = <0x00010000 0x40000>;
};

&slot0_ns_partition {
	reg = <0x00050000 0x30000>;
};

&slot1_partition {
	reg = <0x00080000 0x40000>;
};

&slot1_ns_partition {
	reg = <0x000c0000 0x30000>;
};

&sram0_image {
	reg = <0x20000000 DT_SIZE_K(448)>;
};

&sram0_s {
	reg = <0x20000000 0x40000>;
};    

&sram0_ns {
	reg = <0x20040000 0x30000>;
};

I'm using the TF-M image for the moment (using the board file with ns at the end), I'm not quite sur to understand the use of secure and non secure partition for flash and RAM.

Is thoses partition needed even If I use only secured or only non secured image ? 

Thanks in advance.

Best regards. 
Martin

EDIT:

I have an external flash that I can use for the second image, but I've not configured the partition and the program to use it yet.

Since the error is linked to RAM I though it was not useful to implement it at the moment.

[MartKano]

When not using the /ns (no TF-M) board file I can successfully build with the following output :

[29/29] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       23142 B      34176 B     67.71%
             RAM:        3464 B        64 KB      5.29%
           SRAM1:          0 GB        64 KB      0.00%
        IDT_LIST:          0 GB         2 KB      0.00%
[10/26] Linking C executable zephyr\zephyr_pre0.elf
...
[20/24] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      187452 B       222 KB     82.46%
             RAM:       51044 B        64 KB     77.89%
           SRAM1:          0 GB        64 KB      0.00%
        IDT_LIST:          0 GB         2 KB      0.00%
[21/24] Generating zephyr/app.hex
...
[347/356] Linking CXX executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      201016 B     523776 B     38.38%
             RAM:       89248 B       440 KB     19.81%
        IDT_LIST:          0 GB         2 KB      0.00%
[348/356] Generating zephyr/mcuboot_primary.hex

I was already using 

CONFIG_TFM_PROFILE_TYPE_MINIMAL=y

in the previous configuration.

[AHaug]

Hi, 

Apologies for the long response time. The case were in between a couple of engineers before it came upon my desk. 

So first of I'm a bit curious as to what causes a RAM overflow of 240kB? What is the difference between the MCUboot and non-MCUboot versions?

Have you seen https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/? I would recommend that you go through this w.r.t adding MCUboot and DFU support for your device

My current best guess at what is wrong is that you've defined the SRAM wrongly in your partitioning, maybe the region overlaps with the a secure area

I'm not quite sur to understand the use of secure and non secure partition for flash and RAM.

Not necessarily an answer that completely addresses your uncertainty, but anyways this is the differences between the build types:

A secure build (nrf5340dk_nrf9160 or nrf5340dk/nrf5340/cpuapp for example) means that the application is inherently trusted and runs in the Secure Processing Environment (SPE). This means that everything in your application is trusted and there is no Security by Separation. This can be a security hazard if the user application is buggy or compromised as it can easily access sensitive data such as passwords stored in the flash memory.

A non-secure build (nrf5340dk_nrf9160_ns or nrf5340dk/nrf5340/cpuapp/ns for example) means that the application runs in the Non-Secure Processing Environment (NSPE). In this case, two images are created: the application firmware and the Trusted Firmware M (TF-M). The TF-M runs in the Secure Processing Environment (SPE) and provides the security services needed by the application firmware. This separation ensures that security-sensitive data is in a secure processing environment and access to it is heavily restricted. The TF-M governs the access of the user application to the flash memory and handles security-related tasks, adding an extra layer of security through this separation.

https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-3-elements-of-an-nrf-connect-sdk-application/topic/configuration-files/#multi-image-build does also go into this 

I would recommend that you go through atleast those two lessons in these two courses and then return if you have any follow up questions. I believe that most of your uncertainties may be answered by doing so

Kind regards,
Andreas

[MartKano]

Hello Andreas, 

Sorry for the late response and thanks you for all the information.

I've been through the bootloader lessons, I've tested the hello_world sample with bootloader and get the same error with my custom board.

It seems that the partition manager is not well configurate, for my custom board.

Note that it build well with for the nrf5340dk and that I use the nrf5340dk board file as example for my custom board.

 

Using the Memory report I've seen that there is some difference between the two.

nrf5340dk :

custom board :  

Is there a yml file or conf that I've missed ?

[AHaug]

Hi,

Are you using the same pfj.conf and overlay for these two bords? It seems to me that the nrf5340dk variant does not use it's external flash, leading me to believe that it has not been configured for the DK.

Could you share any prj.conf and overlay files for the firmware you used for the DK?

And are you using QSPI or SPI for external flash purposes?

Kind regards,
Andreas

[MartKano]

Hi, 

I've finally succeed to build the hello world samples with my board:

The use of 

nordic,pm-ext-flash = &mx25r64;

 and 

&mx25r64 {
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        lfs1_part: partition@0 {
            label = "lfs1";
            reg = <0x00000000 0x00800000>;
        };
    };
};

 

make the partition manager doing unwanted partitioning.

If found out that I have to clean "by hand" my build configuration and build folder when playing with those parameters.

But back to my project where after applying the patch explained above I get new errors see :

=== child image mcuboot -  end ===

CMake Warning at C:/ncs/v2.3.0/nrf/modules/mcuboot/CMakeLists.txt:286 (message):
  

          ---------------------------------------------------------
          --- WARNING: Using default MCUBoot key, it should not ---
          --- be used for production.                           ---
          ---------------------------------------------------------
          



-- Build type:  
-- Host:    Windows/AMD64
-- Target:  Generic/arm
-- libmetal version: 1.3.0 (C:/Users/dev/dev/BPI/Concentrateur)
-- Machine: arm
-- open-amp version: 1.3.0 (C:/ncs/v2.3.0/modules/lib/open-amp/open-amp)
-- Host:    Windows/AMD64
-- Target:  Generic/arm
-- Machine: arm
-- C_FLAGS :  -Wall -Wextra
Partition manager failed: The current configuration is invalid because it requires app's size to be less than 0.Unable to fulfill alignment requirement automatically.
Please re-size the configured partition sizes to get a valid configuration.
If you are not able to get a valid configuration either re-evaluate th e
alignment requirements, or use 'static configuration' (see docs) to specify the
 partitioning. Note that aligning more than one partition which shares size
 with the dynamic partition (e.g. 'app')  is not supported.
Failed to partition region flash_primary, size of region: 1048576
Partition Configuration:
littlefs_storage:
  placement:
    align:
      start: 16384
    before:
    - end
  size: 8388608
mcuboot:
  placement:
    before:
    - mcuboot_primary
  size: 49152
mcuboot_pad:
  placement:
    align:
      start: 16384
    before:
    - mcuboot_primary_app
  size: 512
mcuboot_secondary:
  placement:
    after:
    - mcuboot_primary
    align:
      start: 16384
  size: -3694592
tfm:
  placement:
    before:
    - app
  size: 32256

CMake Error at C:/ncs/v2.3.0/nrf/cmake/partition_manager.cmake:304 (message):
  Partition Manager failed, aborting.  Command:
  C:/ncs/toolchains/v2.3.0/opt/bin/python.exe;C:/ncs/v2.3.0/nrf/scripts/partition_manager.py;--input-files;C:/Users/dev/dev/BPI/Concentrateur/build_release/mcuboot/zephyr/include/generated/pm.yml;C:/Users/dev/dev/BPI/Concentrateur/build_release/mcuboot/modules/nrf/subsys/partition_manager/pm.yml.pcd;C:/Users/dev/dev/BPI/Concentrateur/build_release/zephyr/include/generated/pm.yml;C:/Users/dev/dev/BPI/Concentrateur/build_release/modules/nrf/subsys/partition_manager/pm.yml.file_system;C:/Users/dev/dev/BPI/Concentrateur/build_release/modules/nrf/subsys/partition_manager/pm.yml.rpmsg_nrf53;C:/Users/dev/dev/BPI/Concentrateur/build_release/modules/nrf/subsys/partition_manager/pm.yml.tfm;C:/Users/dev/dev/BPI/Concentrateur/build_release/modules/nrf/subsys/partition_manager/pm.yml.trustzone;C:/Users/dev/dev/BPI/Concentrateur/build_release/modules/nrf/subsys/partition_manager/pm.yml.mcuboot;--regions;sram_primary;otp;flash_primary;--output-partitions;C:/Users/dev/dev/BPI/Concentrateur/build_release/partitions.yml;--output-regions;C:/Users/dev/dev/BPI/Concentrateur/build_release/regions.yml;--sram_primary-size;0x80000;--sram_primary-base-address;0x20000000;--sram_primary-placement-strategy;complex;--sram_primary-dynamic-partition;sram_primary;--otp-size;764;--otp-base-address;0xff8100;--otp-placement-strategy;start_to_end;--flash_primary-size;0x100000;--flash_primary-base-address;0x0;--flash_primary-placement-strategy;complex;--flash_primary-device;flash_controller;--flash_primary-default-driver-kconfig;CONFIG_SOC_FLASH_NRF
Call Stack (most recent call first):
  C:/ncs/v2.3.0/zephyr/cmake/modules/kernel.cmake:246 (include)
  C:/ncs/v2.3.0/zephyr/cmake/modules/zephyr_default.cmake:117 (include)
  C:/ncs/v2.3.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  C:/ncs/v2.3.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:97 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Configuring incomplete, errors occurred!
See also "C:/Users/dev/dev/BPI/Concentrateur/build_release/CMakeFiles/CMakeOutput.log".
See also "C:/Users/dev/dev/BPI/Concentrateur/build_release/CMakeFiles/CMakeError.log".
ninja: error: rebuilding 'build.ninja': subcommand failed
FAILED: build.ninja 
C:\ncs\toolchains\v2.3.0\opt\bin\cmake.exe --regenerate-during-build -SC:\Users\dev\dev\BPI\Concentrateur -BC:\Users\dev\dev\BPI\Concentrateur\build_release
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\v2.3.0\opt\bin\cmake.EXE' --build 'c:\Users\dev\dev\BPI\Concentrateur\build_release'

 *  The terminal process terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 

[MartKano]

I'm not using any overlay since I use my custom board files.

And yes I use QSPI external flash feature.

#File system on external flash
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y
CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL=y
CONFIG_FCB=y
CONFIG_PM_PARTITION_REGION_SETTINGS_STORAGE_EXTERNAL=n
CONFIG_PM_PARTITION_SIZE_LITTLEFS=0x00800000

Edit:

Since I want to use QSPI external flash I think I need to put 

        nordic,pm-ext-flash = &mx25r64;

But I need to defined the PM behavior for this flash otherwise it use it as a image space and then I get 

c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: zephyr\zephyr_pre0.elf section `rodata' will not fit in region `FLASH'
c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: region `FLASH' overflowed by 4988 bytes
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Do you have a Idea how can I do so ?