• State Verified Answer
  • Replies 21 replies
  • Subscribers 75 subscribers
  • Views 2835 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 321652
Options

Memory optimization in TF-M enabled applications

Jithin A

Hi, 

We have a project where we are using TF-M application along with DFU and we observe a memory overflow in the TF-M partition when we try to reduce the TF-M partition size.

Attached the memory report.

What is b0 partition and EMPTY_X partitions are used?  How to reduce these partitions size?

We see TF-M is consuming around 270KB and how to reduce this partition at least to its half. 

We basically need the TF-M partition to be minimal to make room for application in non-secure partition.

memory-map.xlsx

Parents
  • 0

    Hi, 

    Can anyone please take a look into this, as this is blocking our further implementation.

    Thank you in advance.

  • 0 in reply to Jithin A

    Hi,

    Jithin A said:
    Can anyone please take a look into this, as this is blocking our further implementation.

    We do normal working weeks, so we do not answer in the weekends. Thank you for your patience.

    Which features do you have in your project?

    What does your bootloader setup look like?
    Which TF-M profile type do you use?

    Have you tried to enable TF-M with different configurations? Do you see the same error then?
    Do you see the same issue for the Hello World sample in  Zephyr, if you add bootloaders and TF-M to it?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi Sigurd,

    Thank you for the response.

    Sigurd Hellesvik said:
    Which features do you have in your project?

    We have enabled BLE, crypto, DFU, ADC, SPI, TWIM, PWM and some timers.

    Sigurd Hellesvik said:
    What does your bootloader setup look like?

    Below are our MCUBoot config setup.

    # Setup secure bootloader
# Flash configurations
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y

# Enable MCUboot and secure bootloader for sgining the image
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_SECURE_BOOT=y

# Enable DFU target
CONFIG_DFU_TARGET=y
CONFIG_IMG_MANAGER=y
CONFIG_DFU_TARGET_MCUBOOT=y
CONFIG_DFU_TARGET_STREAM=y
CONFIG_STREAM_FLASH_ERASE=y
CONFIG_STREAM_FLASH=y
CONFIG_B0_MIN_PARTITION_SIZE=y
CONFIG_NRF53_UPGRADE_NETWORK_CORE=n

    Sigurd Hellesvik said:
    Which TF-M profile type do you use?
    CONFIG_TFM_PROFILE_TYPE_MEDIUM=y

    Sigurd Hellesvik said:
    Have you tried to enable TF-M with different configurations? Do you see the same error then?

    With different configuration I mean, we tried with different TFM profile and we get error if we use TYPE_MINIMAL/TYPE_SMALL.

    Sigurd Hellesvik said:
    Do you see the same issue for the Hello World sample in  Zephyr, if you add bootloaders and TF-M to it?

    No, we get this only in our project setup.

    I did not notice how is memory organisation when I try to build TFM_SPP application with DFU enabled, I can confirm it builds successfully without any overflow issue.

    Attached the prj.conf file for further reference, please let me know if any.sample-prj.conf

  • 0 in reply to Jithin A

    Hi Sigurd,

    Any update on this? 

    Please let me know if anything needed.

  • 0 in reply to Jithin A

    > CONFIG_TFM_PROFILE_TYPE_MEDIUM=y

    Our TF-M implementation officially supports either CONFIG_TFM_PROFILE_TYPE_NOT_SET or CONFIG_TFM_PROFILE_TYPE_MINIMAL . See Running applications with Trusted Firmware-M.

    Jithin A said:
    we get error if we use TYPE_MINIMAL/TYPE_SMALL.

    Which error do you get with minimal?

    What is the reason for not using minimal?

    Minimal is the default conifguration, so it would be good to understand how it behaves with CONFIG_TFM_PROFILE_TYPE_MINIMAL fist.

    Jithin A said:
    Below are our MCUBoot config setup.

    Do you see the same error without CONFIG_SECURE_BOOT=y?
    Do you see the same error without CONFIG_BOOTLOADER_MCUBOOT=y?


  • 0 in reply to Sigurd Hellesvik

    Hi Sigurd,

    Sigurd Hellesvik said:
    What is the reason for not using minimal?

    --> The reason is we have PSA protected storage enabled in our project and I see PSA protected storage is not supported in the TYPE_MINIMAL.

    --> We are now moving to Integrated Trusted Storage instead.

    Sigurd Hellesvik said:
    Do you see the same error without CONFIG_SECURE_BOOT=y?
    Do you see the same error without CONFIG_BOOTLOADER_MCUBOOT=y?

    --> No, we get memory overflow only if we enable bootloader. This is a must as we need to support DFU.

    We updated the SDK to v2.5.2 and we are now working on a sample application (TF-M secure peripheral) with TYPE_MINIMAL setup and we were able to build the project successfully.

    We are trying to port our project implementation without PSA protected storage. So far it is good, and we have limited TF-M partition to use only 96KB using PM CONFIG.

    Thank you for the support, will let you know if this fixes our memory problem.

    • Reply
    • 0 in reply to Sigurd Hellesvik

      Hi Sigurd,

      Sigurd Hellesvik said:
      What is the reason for not using minimal?

      --> The reason is we have PSA protected storage enabled in our project and I see PSA protected storage is not supported in the TYPE_MINIMAL.

      --> We are now moving to Integrated Trusted Storage instead.

      Sigurd Hellesvik said:
      Do you see the same error without CONFIG_SECURE_BOOT=y?
      Do you see the same error without CONFIG_BOOTLOADER_MCUBOOT=y?

      --> No, we get memory overflow only if we enable bootloader. This is a must as we need to support DFU.

      We updated the SDK to v2.5.2 and we are now working on a sample application (TF-M secure peripheral) with TYPE_MINIMAL setup and we were able to build the project successfully.

      We are trying to port our project implementation without PSA protected storage. So far it is good, and we have limited TF-M partition to use only 96KB using PM CONFIG.

      Thank you for the support, will let you know if this fixes our memory problem.

    Children
    • 0 in reply to Jithin A
      Jithin A said:

      --> The reason is we have PSA protected storage enabled in our project and I see PSA protected storage is not supported in the TYPE_MINIMAL.

      --> We are now moving to Integrated Trusted Storage instead.

      To check if there are other ways to do what you need: What kind of data are you storing?

      Are you using this from NSPE or SPE?

      Jithin A said:
      --> No, we get memory overflow only if we enable bootloader. This is a must as we need to support DFU.

      Do you have external flash in your project?

      Depending on the answers to these questions, I hope to be able to give you some advise.

    • 0 in reply to Sigurd Hellesvik
      Sigurd Hellesvik said:
      To check if there are other ways to do what you need: What kind of data are you storing?

      We have a couple of secure keys for AES operations and some secure personal data of the user which are encrypted and stored.

      Sigurd Hellesvik said:
      Are you using this from NSPE or SPE?

      From SPE.

      Sigurd Hellesvik said:
      Do you have external flash in your project?

      No.

    • 0 in reply to Jithin A

      Looking more into this, I think moving from PSA Protected Storage to PSA Internal Trusted Storage is a fair enough option if you are restricted on flash space. Our TF-M developers agree.

      From some testing, it looks like that should save you approximately 30kB.

      Would that be enough?

    • 0 in reply to Sigurd Hellesvik

      Saving 30KB should be OK for us, we may use the additional space for storing user information and stuff.

      We now configuring TFM MINIMAL with ITS enabled, this give us a room for both non-secure application and ITS expansion also.

      Thank you for the support.

    • 0 in reply to Jithin A

      Hi Sigurd,

      We are trying to understand the partition manager configuration and we see _pad on s0, s1, mcuboot.
      Can you please explain what is the use of _pad partition?

      Is it mandatory to have these partitions? if not we can save further memory space for our application.

      We also see 2 EMPTY_x partition which each of size around 15KB. Can't we remove this partition and replace it with the successive partitions? This save us huge memory if we can completely remove EMPTY_x partitions.

      We also noticed, the TFM secure and non-secure partition should be aligned to the NRF_SPU flash region size(0x4000), so removing EMPTY partitions should help us to save around 30KB or more.

      Please help us on defining a partition table without any EMPTY partitions or unused or optional partitions.

    Related
    Terms of service