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

[Sigurd Hellesvik]

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

[jfpastrana]

Hello Marshall  and Sigurd Hellesvik ,

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

[Sigurd Hellesvik]

jfpastrana said:

As I understood, Partition Manager is deprecated, no?

Partition Manager is not deprecated.
If you add MCUboot, partition manager will be enabled to include it as a child image.

jfpastrana said:

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.

When using Partition Manager, the build will be split into multiple images.
The flash overflow can be either in the application or in a child image.
Can you check which part of the build gets the error?

jfpastrana said:

Once I built the application, I see build/partitions.yml but I do know how can I configure it.

Do you mean that you do not know how?
In that case, you do so by using pm_static.yml.

jfpastrana said:

By the moment we are using the nrf9160dk so we do not have a external flash.

If you want to test using external flash with thenRF9160DK, you can.
But you need to reconfigure the DK first though.
Let me know if you want instructions on how to do this.

Regards,
Sigurd Hellesvik

[Marshall]

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

[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,

[Sigurd Hellesvik]

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