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

Static Partition Alignment

hugzy123

Hi,

We have a few questions regarding the pm_static.yml file that's used for defining flash partitions in zephyr. 

Our main questions are regarding alignment; we've created a partition "device_details_partition" where we plan on writing configuration values at manufacturing using nrfjprog via an external nRF53DK. 

These values should be permanent for the lifecycle of the device and will only ever be read in the application firmware, never overwritten. "device_details_partition" needs to have static memory locations so we know where to write/read.

The "device_details_partition" is only 16 bytes long so we're unable to align it to 4kb, we've defined it as follows;

Adding this partition has meant we've had to reduce the size of some other partitions including mcuboot_primary, mcuboot_primary_app and app.

Some questions we had about this implementation:
  1. Could having the size and end address of mcuboot_primary and mcuboot_primary_app not 4kb aligned cause any issues?
  2. Is there a better way we can create "device_details_partition"? A section of flash which can be flashed externally.

Below is our full pm_static.yml

Thanks,
Parents
  • 0

    Hello,

    I assume you only intend to write some data to the device during production, and this data will not change during the lifetime of the product. In that case you can check out the OTP memory in the UICR (fyi: the OTP can be programmed several times during prototype development through the SWD interface, but it's not programmable several times internally from the MCU, which is why I guess they call it OTP). Anyways, you can find a discussion here that may be useful. From the dicussion it seems like it's only if you enable CONFIG_SECURE_BOOT (NSIB) that you can't use the OTP memory region to store your own data:
    https://devzone.nordicsemi.com/f/nordic-q-a/100971/which-registers-in-the-uicr-of-the-nrf5340-are-reserved-for-user-access 

    There is also some description in the nRF5340 PS if you search for 'OTP'.

    Kenneth

  • 0 in reply to Kenneth

    Thanks for your reply.

    Before we moved over to zephyr we used the custom data section of the UICR on our old nRF52 board to store this information, however, we thought we couldn't use UICR with TF-M in zephyr.

    I've just searched through our firmware and found CONFIG_SECURE_BOOT is set to 1 in the multiprotocol_rpmsg networ core image, but not in our application. Would this prevent us from using OTP memory in the UICR?

Reply
  • 0 in reply to Kenneth

    Thanks for your reply.

    Before we moved over to zephyr we used the custom data section of the UICR on our old nRF52 board to store this information, however, we thought we couldn't use UICR with TF-M in zephyr.

    I've just searched through our firmware and found CONFIG_SECURE_BOOT is set to 1 in the multiprotocol_rpmsg networ core image, but not in our application. Would this prevent us from using OTP memory in the UICR?

Children
  • 0 in reply to hugzy123

    Then it shouldnt' be a problem to use UICR for the application as you see fit no. The other case you refer to is for the nRF9160 and does not apply here.

    Kenneth

  • 0 in reply to Kenneth

    If you look further down the post, the nordic employee suggests this is an issue for the nRF5340 too.

    "Unfortunately, this is not yet implemented on our side.

    One can add ranges by appending this array: https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.6.0-ncs3/platform/ext/target/nordic_nrf/nrf9160dk_nrf9160/services/include/tfm_read_ranges.h#L25

    Similarly for nrf5340, https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.6.0-ncs3/platform/ext/target/nordic_nrf/nrf5340dk_nrf5340_cpuapp/services/include/tfm_read_ranges.h"

    I've tried adding some code to read directly from the OTP area of the UICR and using  "tfm_platform_mem_read" to read from the secure area but these both failed.

    Do I first need to add the UICR range into the nRF5340 tfm-read ranges?

    Thanks,

  • 0 in reply to hugzy123

    That was a bummer, I will transfer the case to someone that can suggest how to do this using partion then.

    Kenneth

  • +1 in reply to hugzy123

    Hello,

    Yes, the UICR ranges you want to access from the app need to be added to the tfm-read ranges. Below is an example patch I made for the tfm_read_ranges.h header located in /v2.7.0/nrf/modules/trusted-firmware-m/tfm_boards/services/include:

    And here is the test code I used to verify that it worked:

    Writing the OTP register with nrfjprog:

    Since the OTP region may be used to store secrets, TF-M does not expose this memory region by default. 

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg

    Hi Vidar, 

    Thanks for your reply.

    Apologies I should have mentioned I'm using nRF connect sdk v2.2.0.The tfm_read_ranges.h file is in a different directory but seems to work the same with the changes applied.
    I found the file in "NRF_SDK\2.2.0\nrf\include\tfm\tfm_read_ranges.h"

    I think the function to read from the secure flash are different in this SDK version too, I used "secure_read_word" instead.

    Thanks,

Terms of service