SDK 3.0.0 custom board definition

[Tiit]

I'm having trouble porting my project from the older SDK (2.6.0) to the new SDK. 

I thought the most straightforward way to do that would be to start with a sample project similar to what I want to do. So I took the Matter Window Cover Sample. I have the nRF54L15-DK so I compiled the project for that board and it seems to work.

Now I use the VSCode button to create a new board. After closing VSCode and opening it again I can select my new custom board as the target for the build. It fails as my custom board is pretty much just boilerplate empty board definitions. So I start copying the contents of the nRF54L15-DK board definitions to my own custom board folder. The aim being to get the project to compile for the same dev kit with my custom board as the target. Ideally I would make no changes to the files but due to custom name I still have to do that. This also means I have to make another partition manager static definition file. I just copy the one used for the DK build and rename it for my custom board.

After fighting with some very hard to fix devicetree errors I get compilation process to reach the partition manager stage and there is something weird happening there. I have the exact same contents for the static definition file as the DK but for my board the build fails complaining about too many gaps in the partitions. I'm attaching the actual file I use for this.

pm_static_blindy_v3_nrf54l15_cpuapp.zip

The error I get from partition manager is this:

-- Found partition manager static configuration : /home/tiit/code/nordic/blindy_matter/pm_static_blindy_v3_nrf54l15_cpuapp.yml
Partition 'mcuboot' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_pad' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary_app' is not included in the dynamic resolving since it is statically defined.
Partition 'settings_storage' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_secondary' is not included in the dynamic resolving since it is statically defined.
Partition manager failed: Incorrect amount of gaps found in static configuration. There must be exactly one gap in the static configuration to support placing the dynamic partitions (such as 'app'). Gaps found (2):0xd800-0x165000 0x17d000-0x172000 The most common solution to this problem is to fill the smallest of these gaps with statically defined partition(s) until there is only one gap left. Alternatively re-order the already defined static partitions so that only one gap remains.
Failed to partition region flash_primary, size of region: 1462272
Partition Configuration:
app:
  size: 1460224
factory_data:
  size: 4096
mcuboot:
  size: 53248
mcuboot_pad:
  size: 2048
mcuboot_primary:
  size: 1462272
mcuboot_primary_app:
  size: 1460224
settings_storage:
  size: 40960

-- Configuring incomplete, errors occurred!

Can you please check what I'm doing wrong here to cause this. This is somehow caused by using the custom board definition. I'm also attaching the whole custom board folder here just in case you can see something weird in there. This is just the folder that has to be extracted into the boards folder and after a VSCode restart it appears as a target for the build.

soma.zip

Hoping to hear back from you after the Easter Holidays,

Tiit

[Tiit]

Hi Andreas,

Thank you for the detailed response to this. Unfortunately I had to delete the newer SDK versions since they seem to break v2.7.0 builds somehow. So I will only be able to test this next week after reinstalling everything again. 

But I do have a question. In the fix for MCUboot you say I have to add the overlay and conf in the sysbuild/mcuboot/boards directory. As I understand that is basically the overlay that only MCUboot will use. I'm not 100% sure how these conf and overlay things work but my understanding was that they basically get merged with the devicetree and conf files for the selected board and if I wanted to I could just manually merge and skip the overlay parts. I'm asking this because having the board definition broken into multiple folders seems like a place where we can easily forget to change something duplicated and cause issues some time later when we make changes to our board again. The current version we have the whole devicetree and board conf nicely contained in one folder. If that is not possible I can live with this as well but I just wanted to ask to be sure.

I'm not sure why step 3 is necessary. The thing about adding the board to board roots. For me the extension picked up the custom board after a relaunch if it was created in the project folder in the correct place. I'm asking this because we keep our project in a git repository and having all developer always have to add something in VSCode seems like it would not be ideal.

Tiit

[AHaug]

Hello,

Tiit said:

Unfortunately I had to delete the newer SDK versions since they seem to break v2.7.0 builds somehow. So I will only be able to test this next week after reinstalling everything again. 

No worries, take your time.

Tiit said:

As I understand that is basically the overlay that only MCUboot will use.

Correct, this is the overlay and configurations specifically for the MCUboot image.

Tiit said:

I'm not 100% sure how these conf and overlay things work but my understanding was that they basically get merged with the devicetree and conf files for the selected board and if I wanted to I could just manually merge and skip the overlay parts.

If you don't have any overlay and configurations added to sysbuild/<companion_component>/, where companion component in this case is mcuboot, then the build system will only build a default mcuboot given that you've defined said config within sysbuild.conf. 

None of the changes within app.overlay, prj.conf or sysbuild.conf present in the root level of your project is applied to any of the companion components.

This is similar to how it previously was done with child/parent images, where you had a structure with child_image/mcuboot/prj.conf and mcuboot.overlay instead.

Tiit said:

. I'm asking this because having the board definition broken into multiple folders seems like a place where we can easily forget to change something duplicated and cause issues some time later when we make changes to our board again.

Tiit said:

The current version we have the whole devicetree and board conf nicely contained in one folder. If that is not possible I can live with this as well but I just wanted to ask to be sure.

Here's an important clarification that I think might reassure you. The board definition itself is not broken into multiple places.

Everything w.r.t your board will be placed within the boards folder (the one you sent me), which you can place wherever you wish as long as the build system and the extension knows where it is residing (see my comments w.r.t your question about step 3 for more details). I placed it within the boards folder of the project because I wanted to have it located somewhere locally on my computer related to this specific case.

In the case of the exercise I did with getting the sample to build with the "custom" board, i.e basically a 54l15dk with a different name, was to make modifications to the board for just that project by adding some required features that a Matter application needs. Among these change I had to state that we should use an external flash, that MCUboot needs to be aware that the secondary partition should reside on the external flash and that MCUboot should use a specific SPI to communicate with the external flash. For a nRF52840 based project this would've been the same, but I could've chosen to use QSPI instead of SPI.

For your project the same will apply. If your bootloader needs modifications, the build system will not know about the features you need to add unless you add the configurations to the sysbuild folder for the companion component

The overlays are as you said laid over top for that specific project, and it has nothing to do with the board configuration themselves. This allows you (and us) to have one board configuration, lets say the nRF54L15DK configuration, and then modify it for each unique project by changing the board through overlays that only applies for that project. The change could be as minimal as for project A we want to use GPIO1.0 for driving a peripheral, whereas for project B we want to use GPIO1.1.

This image from  https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-1-nrf-connect-sdk-introduction/topic/nrf-connect-sdk-structure-and-content/ should illustrate this somewhat more.

That said, if you have a board that will only be used for 1 project and the base will never see the need to be slightly modified to fit another application, then you can have your boards placed locally within the project themselves.

Just linking this once more for reference: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-sysbuild/topic/sysbuild-explained/ 

Tiit said:

I'm not sure why step 3 is necessary. The thing about adding the board to board roots. For me the extension picked up the custom board after a relaunch if it was created in the project folder in the correct place.

If you've added the board to a folder that the build system knows as a board root (for instance <sdk>/zephyr/boards or <sdk>/nrf/boards which are default added as board root folders), then the board will automatically be picked up by any project within that SDK instance.

Ah, I didn't see the board when adding it to the project structure before I added the path to board.root. I guess that's because I didn't relaunch the extension before trying to add the build configuration.

Here's an explanation I got w.r.t how this should work: if you add it to your projects board folder, it will be recognized as a board you can use for that project after relaunching/reloading the app. 

TLDR (for this item), the step is not mandatory, but it is an alternative to make sure that the custom board is found by the build system.

Let me know if that makes sense and feel free to ask follow ups if anything is unclear

And also, I recommend you getting your custom board working in NCS 2.7.0 (or newer where sysbuild is used) with simpler applications than a Matter sample first. For instance <sdk>zephyr/samples/sysbuild/with_mcuboot is a good start. This is a hello world sample that enables MCUboot through sysbuild.conf

Kind regards,
Andreas

[Tiit]

Hi Andreas,

I tried your suggestions now and it does compile now. So thank you for that. And I already have a working application in production on NCS 2.5.0. In 2.7.0 we are trying to get Matter and Zigbee to compile in one project so that is a weird case. But for Matter in production I want to use whatever is newest at the time we go into production with that.

So now that 3.0.1 compiles for me I tried flashing it to the dev board. And it fails. I tried the one you sent here and even a fresh copy of the SDK. They all work when compiled for the DK and all fail to do anything if compiled for my board (that should now be identical to the DK). Something is still not right with the board files I guess. I'm not sure how to proceed with this as I'm now not even seeing any errors - it just does nothing. I tried debugging but that also didn't work (I had to learn how to do that for 2.7.0 but here it just doesn't work for some reason). 

You said I had to add  CONFIG_ZMS=y to the overlay (which I did) but if I have to do that and the DK does not maybe that means there is still some file that the DK links into the build but my custom board does not. You should be able to recreate this with the project you sent me. 

Also just to let you know for the future - the project you sent me already had a build configuration but that does not work at all for me. I'm working on Ubuntu and I guess you were using Windows and there might be some weird issue with build folders moving like that. Dong my own configuration in that project does still result in a successful compilation (and still a dead image).

Tiit

[AHaug]

Hello,

Glad to hear that somethings working at least

Tiit said:

NCS 2.5.0. In 2.7.0 we are trying to get Matter and Zigbee to compile in one project so that is a weird case.

TBH this is another case in itself, but since I'm curious I'm wondering how you're doing this in practice? Are you swapping Matter for Zigbee, or do you have your own custom solution that handles multiprotocol with Zigbee and Matter?

Tiit said:

So now that 3.0.1 compiles for me I tried flashing it to the dev board. And it fails.

Just to be clear, so that there's no false assumptions from my sake. Could you clarify what you flashed to what? I.e the sample I sent? Your firmware? Another Matter sample from 3.0.1? To the nRF54L15DK or to your custom board?

At what point does it fail? Is the image not booting up, or not flashing?

Tiit said:

You said I had to add  CONFIG_ZMS=y to the overlay (which I did) but if I have to do that and the DK does not maybe that means there is still some file that the DK links into the build but my custom board does not. You should be able to recreate this with the project you sent me. 

This might be the case, but I think this is specific to the Matter sample I based my debugging on.

Tiit said:

I'm not sure how to proceed with this as I'm now not even seeing any errors - it just does nothing. I tried debugging but that also didn't work (I had to learn how to do that for 2.7.0 but here it just doesn't work for some reason). 

First thing first I think we need to start more basic. 

1. Get the custom board working with something simpler using hw model 2 and sysbuild
   1. https://github.com/nrfconnect/sdk-zephyr/tree/main/samples/sysbuild/with_mcuboot/sysbuild 
   2. https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-sysbuild/topic/sysbuild-explained/ exercise 1 and 2
2. If it builds and flashes, we need to do some debugging to see where it fails https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-2-debugging/
3. If it does not build, we need to look at the build errors 

Tiit said:

Also just to let you know for the future - the project you sent me already had a build configuration but that does not work at all for me. I'm working on Ubuntu and I guess you were using Windows and there might be some weird issue with build folders moving like that. Dong my own configuration in that project does still result in a successful compilation (and still a dead image).

Ah, makes sense. 

Kind regards,
Andreas