How to configure memory layout in Asset Tracker v2 app

[jfpastrana]

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

[jfpastrana]

Hello Sigurd Hellesvik ,

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

[Sigurd Hellesvik]

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

[jfpastrana]

Hello Sigurd Hellesvik ,

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

[Sigurd Hellesvik]

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

[jfpastrana]

Hello Sigurd Hellesvik ,

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:

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:
    - mcuboot_secondary
  region: flash_primary
  size: 0x1000
app:
  address: 0x1c200
  end_address: 0x86000
  region: flash_primary
  size: 0x69e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0x86000
  orig_span: &id001
  - tfm
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x76000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0x86000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0x75e00
  span: *id002
mcuboot_secondary:
  address: 0x86000
  end_address: 0xfc000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x8000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x76000
nonsecure_storage:
  address: 0xfd000
  end_address: 0xff000
  orig_span: &id003
  - settings_storage
  region: flash_primary
  size: 0x2000
  span: *id003
nrf_modem_lib_ctrl:
  address: 0x20008000
  end_address: 0x200084e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - tfm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x2000a4e8
  end_address: 0x2000c4e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20008000
  end_address: 0x2000c4e8
  orig_span: &id004
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id004
nrf_modem_lib_tx:
  address: 0x200084e8
  end_address: 0x2000a4e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
settings_storage:
  address: 0xfd000
  end_address: 0xff000
  inside:
  - nonsecure_storage
  placement:
    align:
      start: 0x8000
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_nonsecure:
  address: 0x20008000
  end_address: 0x20040000
  orig_span: &id005
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x38000
  span: *id005
sram_primary:
  address: 0x2000c4e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x33b18
sram_secure:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id006
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id006
tfm:
  address: 0x10200
  end_address: 0x1c200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0xc000
tfm_nonsecure:
  address: 0x1c200
  end_address: 0x86000
  orig_span: &id007
  - app
  region: flash_primary
  size: 0x69e00
  span: *id007
tfm_secure:
  address: 0x10000
  end_address: 0x1c200
  orig_span: &id008
  - mcuboot_pad
  - tfm
  region: flash_primary
  size: 0xc200
  span: *id008
tfm_sram:
  address: 0x20000000
  end_address: 0x20008000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x8000

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:

--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):

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,