How to configure memory layout in Asset Tracker v2 app

Hello,

We are currently using NRF Connect SDK 2.2.0 and even more specifically the Asset Tracker v2 application in nrf9160dk board. By the moment we are only including some dependencies which our future application will need. This dependencies include new kernel modules and new application libraries (only modified CMakeList).

After building the application, when is time to link we have the following error:

"zephyr/zephyr_pre0.elf section `rodata' will not fit in region `FLASH'"

I saw other posts related to mine like this one MCUBootloader won't build for custom board - zephyr/zephyr_pre0.elf section `text' will not fit in region `FLASH' but not sure if we have the same issue.

Therefore, How can i modified the memory layout of Asset tracker application in order to give it more space to the APP? 

This is my current memory layout:

Best regards,

Javier

Parents
  • Have a look at Marshalls suggestions, they are good.
    I also recommend optimizing flash usage before changing the partitioning.

    If you need to change the flash partitioning, you use static partitioning.

    1. Have a look at pm_static.yml for a sample
    2. Have a look at build/partitions.yml for your projects current partitioning.
    3. Create your own pm_static.yml

    Regards,
    Sigurd Hellesvik

  • Hello   and  ,

    By the moment we are using the nrf9160dk so we do not have a external flash. However, using the 1MB internal flash should be enough, if you have a look to the memory layout of the Asset Tracker, there is a lot of free space:

    We are in a early stage, so, we do not need FOTA now as well as I did not start with the project optimisations, as I said, I only included some dependencies to Asset Tracker, I did not include any development yet. If I have to start with optimisations now.... it is not promising.

    What is AT2?

    As I understood, Partition Manager is deprecated, no? Asset Tracker uses the information of the Device Tree to allocate each partition, no? Once I built the application, I see build/partitions.yml but I do know how can I configure it.

    Regards

  • That free space is for the FOTA Image to be stored. 

    AT2 = Asset Tracker 2 (sorry) 

    If you are not going to upgrade the boot loader (in the field), you can turn off the first stage bootloader in your prj.conf

    #we are never going to upgrade the bootloader in the field.

    CONFIG_SECURE_BOOT=n
    CONFIG_BUILD_S1_VARIANT=n
    I'm using the dynamic partition manager, so it all gets a bit opaque, as to how to disable the image second slot, (as I just moved mine to external flash), but it should be doable. 
    perhaps this is a place to start. 
    CONFIG_FOTA_DOWNLOAD=n
  • Hello  ,

    I mistake Partition Manager with Secure Partition Manager, which is in deprecated status.

    I have included MCUBoot.

    The image which is failing during the linking stage is "tfm". By the moment, I will follow your recommendations of reducing the code size as well as removing unnecessary dependencies. 

    Therefore, If I understood well, Partition Manager is configuring automatically each partition, no? Then, the only way that I have now to solve this is issue is reducing the size or going to a static approach. 

    What do you recommend?

    Regards

  • jfpastrana said:
    Therefore, If I understood well, Partition Manager is configuring automatically each partition, no?

    That is correct.

    jfpastrana said:
    Then, the only way that I have now to solve this is issue is reducing the size or going to a static approach. 

    There might be some Kconfig options you can use instead. It depends.

    jfpastrana said:
    What do you recommend?

    First:
    Is the flash space limitation in the application or a child image?

    Regards,
    Sigurd Hellesvik

  • Hello  ,

    First of all thank you for the answer.

    And regarding your question, the limitation is on the child image, to be more precise, s1_image.

    The last days, I was trying to reduce the memory used but I did not success yet.

    Regards

  • Hi,

    jfpastrana said:
    And regarding your question, the limitation is on the child image, to be more precise, s1_image.

    That would mean that MCUboot is is the one with too little space.

    Have a look at this child_image/mcuboot.conf from the Machine Learning sample to see an example of how to reduce MCUboot flash size.

    Also see my explanation on How to configure the bootloader.

    For more general tips, see our Optimizing application docs.

    Does this help?

    Regards,
    Sigurd Hellesvik

Reply Children
  • Hello  ,

    It was helping the information that you shared with me. I was optimising the application, however it is not enough. I am overlapping 235412bytes... quite a lot.

    I was doing some test using static partition, it looks promising. However, I would like to know how to increase the flash_primary partition.

     Below you can find the static configuration of my application:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    EMPTY_0:
    address: 0xc000
    end_address: 0x10000
    placement:
    before:
    - mcuboot_pad
    region: flash_primary
    size: 0x4000
    EMPTY_1:
    address: 0xff000
    end_address: 0x100000
    placement:
    after:
    - settings_storage
    region: flash_primary
    size: 0x1000
    EMPTY_2:
    address: 0xfc000
    end_address: 0xfd000
    placement:
    after:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    This configuration is currently working AT2 application, if we focus on "EMPTY_1" partition, we can see that the ending address is 0x100000. If I try to increase this partition to 0x180000, for instance. It will throw an error:

    However, I think that the problem comes from flash_primary region:

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

    As  can see in the error the flash_primary_size is 0x100000, therefore it is not going to fit. PM is not taking into consideration the ending addrees.

    How can I increase this region? as I can see here, we have lot of space available.

    Best regards,

  • jfpastrana said:

    As  can see in the error the flash_primary_size is 0x100000, therefore it is not going to fit. PM is not taking into consideration the ending addrees.

    How can I increase this region? as I can see here, we have lot of space available.

    I think the figure you are looking at can be misleading.

    The nRF9160 has a 1024 kB flash, which is 1MB = 0x0-0x100 000. For a source on the converting, I can give stack overflow.

    So this is correct:

    jfpastrana said:
    flash_primary_size is 0x100000

    Regards,
    Sigurd Hellesvik

  • Hello  ,

    Thanks for the clarification, I misunderstood this size due to the following image:

    My mistake.

    Is there any possibility to place the app in the external flash? The other possibility what I am considering is to flash only the Application without bootloader, I am doing a proof of concept and I do not need it now. Does it possible in AT2?

    Thank you very much for the support,

  • Hi,

    jfpastrana said:
    Is there any possibility to place the app in the external flash?

    Placing the app in an external flash could be possible using Execute In Place (XIP), but it is not recommended.

    Instead, start by moving secondary and storage partitions to external flash.

    jfpastrana said:
     Below you can find the static configuration of my application:

    From this, I would suggest placing mcuboot_secondary and nonsecure_storage in external flash as a start.
    Let me know how the flash space looks after that.

    Regards,
    Sigurd Hellesvik