Attachments (0)
Nordic Case Info
  • Case ID: 327892
Options

[MCU BOOT] `RAM' overflowed

Martdur

Hello, 

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

Fullscreen
1
2
3
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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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: 

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
[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%
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
4
5
6
7
8
9
[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%
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

In my _cpuapp_common.dts

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/ {
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 */
};
};
};
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

In my cpuapp_partition_conf.dts : 

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
&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 {
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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.

Parents
  • 0

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

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    [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%
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I was already using 

    Fullscreen
    1
    CONFIG_TFM_PROFILE_TYPE_MINIMAL=y
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    in the previous configuration.
  • 0 in reply to Martdur

    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

  • 0 in reply to AHaug

    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 ?

  • 0 in reply to Martdur

    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

  • 0 in reply to AHaug

    Hi, 

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

    The use of 

    Fullscreen
    1
    nordic,pm-ext-flash = &mx25r64;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
     and 
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    &mx25r64 {
    partitions {
    compatible = "fixed-partitions";
    #address-cells = <1>;
    #size-cells = <1>;
    lfs1_part: partition@0 {
    label = "lfs1";
    reg = <0x00000000 0x00800000>;
    };
    };
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
     

    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 :

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    === 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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Martdur

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

    And yes I use QSPI external flash feature.

    Fullscreen
    1
    2
    3
    4
    5
    6
    #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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Edit:

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

    Fullscreen
    1
    nordic,pm-ext-flash = &mx25r64;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

    Fullscreen
    1
    2
    3
    4
    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.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Do you have a Idea how can I do so ? 

Reply
  • 0 in reply to Martdur

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

    And yes I use QSPI external flash feature.

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Edit:

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

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Do you have a Idea how can I do so ? 

Children
  • 0 in reply to Martdur

    So I've try using a static partition : 

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    But I get the same error : 

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Martdur

    I managed to make it work the issues was that I have to set the proper configuration for both files: 

    • In mcuboot.conf
      Fullscreen
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    • In the prj.conf
      Fullscreen
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    What I've understand is that 

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    was enable by default in the mcuboot.conf making the partition manager create a partition for the image 2, this will introduce a conflict with the LittleFs image since 
    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    .

    Edit:

    As discussed above the chosen  

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    has to be set too.

    Thanks for the help.

    Kinds regards.

    Martin

  • 0 in reply to Martdur

    Hi,

    Apologies for the long response time, I've been out of office. I will go through your information today and come back with a response

    What I see immediately is that your static partition is a bit wrong, the "size" part of your littlefs_storage region needs to be aligned with the rest of the parameters for that partition:

    You will most likely get the flash overflow error again, but could you fix this and see if you do?

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Oh and I see you just replied with another update! Happy to hear that you resolved it with those configurations, and thank you very much for sharing your progress!

    Kind regards,
    Andreas

Terms of service