Custom board with Static partitions, MCUboot and Sysbuild

Hello!

I am using an nRF Connect SDK V2.9.0 with a nrf54l15. I want to set up a project with a custom board. I want to add DFU in the future, so there must be MCUboot bootloader and static partitions defined.

I took the zephyr/samples/sysbuild/with_mcuboot sample. Then I compiled it for the nrf54l15dk. From the build directory, I took the partitions.yml file and copied it as pm_static.yml to the root folder of my project. I enabled the partition manager in the sysbuild.conf file, compiled the project again and flashed it - everything works fine and the board prints some logs, as described in the sample readme.

Then, using the VScode extension, I have created a custom board. And I slightly adjusted it:

1) Enabled UART, so I would be able to get some logs, when I run the code on a nrf54l15dk

2) Added missing zephyr,flash-controller chosen node

3) Reduced the boot_partition size to 48K, so it matches the pm_static.yml

The code compiles for the custom board, but when I flash it and reset the board - nothing happens.
Using a debugger, I found out that the bootloader starts, but is unable to find an image. Also, for some reason, logs are disabled in the bootloader.
With a help of the nrfjprog, I have dumped the MCU's memory and inspected the dump. In the dump, I can see the image at the expected address.

So the problem is that I cannot properly set up the project for a custom board, while it works fine for a board from the SDK.
Here is a repository with my code, that exposes the issue I am facing: link

Parents
  • Hi,

    Using a debugger, I found out that the bootloader starts, but is unable to find an image. A

    I think I see why. In your pm_static, the bootloader pad region stops at 0xc800, while the application (mcuboot_primary) starts at 0xc000, i.e before the bootloader region (mcuboot + mcuboot pad) ends

    Let me know if resolving the address starts resolves the bootup issues!

    Also, you might already gone through these resources, but I would recommend that you have a look at the newly updated lesson 8 and lesson 9 in the academy pages w.r.t sysbuild and partitioning 

    https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-sysbuild/topic/sysbuild-explained/ 

    https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/ 

    All exercises solutions should compile out of the box for the nRF54L15.

    Kind regards,
    Andreas

  • Hi!
    Thank you for the answer.
    I am not sure, that this is the problem because:
    1. If I compile the project for the nrf54l15dk/nrf54l15/cpuapp board target everything works fine (pm_static.yml is left unchanged)

    2. Here in the SDK application the mcuboot_pad stops at 0x7800, while the mcuboot_primary
    starts at 0x7000. Which looks similar to my pm_static, but they just use smaller partition for the bootloader

  • Hi,

    DmytroSes said:

    1. If I compile the project for the nrf54l15dk/nrf54l15/cpuapp board target everything works fine (pm_static.yml is left unchanged)

    2. Here in the SDK application the mcuboot_pad stops at 0x7800, while the mcuboot_primary
    starts at 0x7000. Which looks similar to my pm_static, but they just use smaller partition for the bootloader

    Ah, yes. I was a bit too quick in my previous reply.  RE: Flash Partition Management with Trusted Firmware-M explains the partitioning a bit better as well.

    When you apply your changes to the pm_static that works. Have you made sure to reduce and increase any relevant gaps that occurs with the reduction of the bootloader partition?

    Could you also paste any build and/or device logs?

    Kind regards,
    Andreas

  • Thanks for the link to partitioning explanation! I was searching for this.

    Have you made sure to reduce and increase any relevant gaps that occurs with the reduction of the bootloader partition?

    The only thing I changed was the boot_partition size in the board dts file (which is, I think, is unnecessary). The pm_static.yml file has all the partitions taken from the partitions.yml, as described in one of the Nordic lessons. I have done no changes to the pm_static.yml.
    I have also run Memory report tool for both targets (my custom board and the DK) and the partitions are completely identical there.

    The device sends no logs, while in Mcuboot, the logs are not even compiled (which is strange for me, because there are logs for the DK target).

    Here are the build logs for my custom board target:

    And here are the build logs for the DK target:

  • I have managed to solve the problem with logs. Here is what the bootloader prints for my board:

    And here what it prints for the DK:

  • So with some more investigation I have found, that the bootloader cannot properly read image headers. In both cases it reads from the 0xc000 address and in both cases I can see the image magic number through a debugger memory view at this address. However, on my custom board the image headers structure in bootloader is for some reason empty (all the values are 0), like there is something, that prevents the bootloader reading from that area of memory. And because of that the bootloader fails to find the image.

  • Here on the screenshot you can see, that there is a valid magic number at 0xc000, but the bootloader did not parse it. When I run the bootloader compiled for the devkit target, I get some valid numbers in the state.imgs[0][0].hdr structure at this step.

Reply
  • Here on the screenshot you can see, that there is a valid magic number at 0xc000, but the bootloader did not parse it. When I run the bootloader compiled for the devkit target, I get some valid numbers in the state.imgs[0][0].hdr structure at this step.

Children
No Data