Partition Manager: Accessing partition information from software, changing reserved memory layout later, preserving partitions while flashing etc.

[puz_md]

Hi, I use MCUboot and have defined some specific partitions at the end of the nRF5340 flash memory (placement and size of application slots have been adjusted accordingly):

my_reserved:
  address: 0xf8000
  end_address: 0xfe000
  placement:
    before:
    - my_data
  region: flash_primary
  size: 0x6000
my_data:
  address: 0xfe000
  end_address: 0xff000
  placement:
    before:
    - my_pcbinfo
  region: flash_primary
  size: 0x1000
my_pcbinfo:
  address: 0xff000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x1000

Question 1:
Partition "my_pcbinfo" shall be used by the PCB manufacturer to program some information in the final flash page, like production date, hardware revision, serial number etc.
We intend to program this information via JTAG (SEGGER JLink) at the PCB manufacturer's location, before the application software is programmed.
There is no child image defining data in this partition.
Will this partition be preserved throughout the product lifecycle, especially when MCUboot including the initial application software (merged_domains.hex) is programmed via JLink or west?

Question 2:
Is there any fancy way to get the partition offset and size from within my application (without hardcoding the memory address which would mean double data definitions, which I want to avoid)? If possible, via a macro that can be used at build time.
My intention is to define a struct and link it to the memory location, something like this (I don't know how to define an empty structture variable at some memory location, so I use a macro in the second variant):

volatile const struct smy_pcbinfo* pmy_pcbinfo = (volatile const struct smy_pcbinfo*)MY_PCBINFO_OFFSET

#define my_pcbinfo (*(volatile const struct smy_pcbinfo*)MY_PCBINFO_OFFSET)

Question 3:
I have reserved some memory in the partition my_reserved. Would it be possible to split this partition into smaller fractions at a later time, with preserving compatibility to earlier software versions? Concretely, I program my hardware with MCUboot and the initial application (which does not use the my_reserved partition), and in the future, I split the partition into smaller sections in pm_static.yml and access the new partitions from within my updated application. Can I use mcumgr to update the application, which is aware of the new partitioning after updating? Will this work?

Question 4:
How does MCUboot know about the partitioning of the software, especially the slot locations for software updates? Is the partition table (created from pm_static.yml) saved somewhere within the MCUboot code? Is it saved in the application code? I found this ticket which suggests that MCUboot is compiled before the partition manager is invoked, so I do not understand how it can obtain the partition information.
https://devzone.nordicsemi.com/f/nordic-q-a/97478/partition-manager-and-device-tree-partitions/414434
(See Marte's first reply)
Is it possible to use the initially programmed MCUmgr (which only might know about the my_reserved partition at build time) to update newly defined sub-partitions within the my_reserved space later (without erasing unaffected pages)?

The basic concept of this approach is to reserve some flexibility for future development when it comes to data handling. And to define a basic layer (MCUboot and two application slots) at early development stage with allowing the devices to be updated later to provide more functionality.

Question 5:
Regarding the my_pcbinfo partition, would it also be possible to use the OTP memory (768 bytes) for this kind of information? The information would probably be protected better this way. Or is the OTP memory being used by other nRF Connect SDK components?
Did I understand correctly that the OTP memory will still be erased when performing a complete chip erase?

Best regards,
Michael

[Sigurd Hellesvik]

Hi,

See 5. first.

1:

If you want to do this using the child-image feature, you can see this unofficial sample.
However, if all you want is to add a hex to some addr with nrfjprog, you can use the mergehex CLI tool to combine your hex to the hex that is being flashed. To see how hex files are generated by the build, build with "west -v build ...".

2:

#include <pm_config.h>

3:

I have reserved some memory in the partition my_reserved. Would it be possible to split this partition into smaller fractions at a later time, with preserving compatibility to earlier software versions?

Yes, the partition manager can make sub-partitions.
And MCUboot is able to change partitioning of parts of flash it does not need to know the addr of. The "untouchable" partitions are mcuboot, mcuboot_primary, mcuboot_secondary and other partitions MCUboot update/swap. Mark that it is only the start and end of these that must be set. Sub-partitions inside those can change.

4:

How does MCUboot know about the partitioning of the software, especially the slot locations for software updates?

Partitioning is shared between images. It goes something like this:

I have made a nice figure that kinda shows the concept over here.

Is it possible to use the initially programmed MCUmgr (which only might know about the my_reserved partition at build time) to update newly defined sub-partitions within the my_reserved space later (without erasing unaffected pages)?

Well. You can update a custom partition over DFU. However, that requires you to configure MCUboot for multiple partitions.
It would be a lot easier to just update the custom data in your application or by using the SMP File management feature available in MCUmgr. What do you think about that?
Erasing the data, on the other hand, is easy. For example, our nRF Device Manager app for mobile will delete other partitions as well by default when doing OTA.

5:

Yes, you can use OTP for this. And I think this might be a better solution for your use-case than a custom partition.
OTP is basically the CUSTOMER registers from previous chips, but with more features.
You should be able to program this either as part of merged.hex (a bit hard to generate) or with nrfjprog before/after programming the app (takes a bit more time in production).
I do not think that any of our drivers should use OTP for anything, but I recommend that you check if you app does this to be certain.

The only downside is that you can not update the OTP over DFU, as it is One Time Programmable.
If you need new values here, the workaround would be to upload the new ones to new OTP registers. This would give you a limited amount of updates and require some more logic in the code to handle.

Regards,
Sigurd Hellesvik