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

[AHaug]

Hello Tiit,

A couple of starting points here before I get back to you early in the coming week,

1. You state that you've based your project on the Matter window cover sample, is this from 2.6.0 or is it from a newer version of NCS (if so which version are you referring to with "to the new SDK"?  Nonetheless, there will be quite a few changes between 2.6.0 and 2.9.1 or 3.0.0 (of those are the versions you're referring to), so we'll just go through the hoops until we get there.
   
   
2. The first thing I would like you to verify is the hardware model you're using. Since you're based on 2.6.0 I assume it is hwm2, but could you verify if you've gone through the steps here? https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/migration/migration_hwmv2.html 
   
   
3. The next is, which revision of the nRF54L15 SoC are you using? I.e what I'm asking is if your SoC revision is compatible with the SDK version you intend to use
   

• I just copy the one used for the DK build and rename it for my custom board.
I would say that this is the way to go, unless there are certain things that are set up in the nrf54l15Dk's board files that you've not attached somehow. Could you verify if you've done the following:
1. Build the window cover sample for the nrf54l15dk
2. Checked the generated partitions.yml located within build (or build/your_app/ or build/your_app/zephyr I can't quite remember, but there should only be one)
3. Copy the contents of that and attach in a static partitioning file that your custom board will use
4. Since you're migrating from child/parent images used in NCS 2.6.0 I would also recommend you to have a look at the sysbuild academy lesson unless you've already done so: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-sysbuild/topic/sysbuild-explained/ 

Let me know about this and I'll get back to you when I get back in office next week

Kind regards,
Andreas

[Tiit]

Hi Andreas,

Thank you for getting back to me so fast and sorry I wasn't able to respond sooner.

1. I used VSCode to install SDK 3.0.0 and created a new application from the example included with that (using the built in button for that). I changed nothing in that example and built it for my nRF54L15-DK. This worked and I was able to flash and add the device to Alexa through the Echo with Matter support (it did complain about the device not being certified but that is normal as I understand).

2. My original code is based on SDK 2.5.0 with some changes it does work with 2.6.0 and that is what I have been using to develop the Matter branch of our firmware. There are still issues with that but the Matter build itself works and can also be added to most Matter controllers with the warning about certification. I spent two days trying to port that to SDK 3.0.0 without luck. So in frustration I decided to just take the clean example from 3.0.0 and get that example to build on my custom board as a starting point. I have a button and an RGB led on my board so the example should be very close to compatible. I also have the exact same external memory chip and had experience with doing a similar thing when we first started our firmware on 2.5.0. Now I'm guessing the hardware model thing should be correct when I start from the example in 3.0.0. SO what I want to do first is take the code that is working on the dev board and get this to compile on a custom board that still describes the exact same dev board. I'm not sure if I'm explaining this right. What I want to do is compile the clean example code but instead of selecting "nrf54l15dk/nrf54l15/cpuapp" I want to select "blindy_v3/nrf54l15/cpuapp". I clicked create new board and named it "blindy_v3". This created the board and I can select it as the target. But this fails because the board created is pretty much empty. Now I tried copying in all the required things from the SDK folders that defined the devkit but it still fails to build.

3. I think my dev kit has the engineering sample. The markings on the chip say QFAABB. The sticker on the dev kit says PCA10156, 0.9.1, 2024.44

The example does build and it does generate the partitions.yml file. But there is already a static partition file that is defined for each board in the project folder and I copied the one for the DK with no changes and I can see in the build process that the correct file does get included (Found partition manager static configuration :/home/tiit/code/nordic/blindy_matter/pm_static_blindy_v3_nrf54l15_cpuapp.yml). Should I just replace that with the one from the successful DK build? If so - why would it not work with the copy that works for the DK build? I would feel hesitant using this in production without understanding the reason for the problem.

4. I will definitely take a look. I did use sysbuild for the Matter version already but I don't really understand it. I just know that whenever I make a build configuration I have to select sysbuild or things will fail in weird and interesting ways.

Tiit

[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

[Tiit]

AHaug said:

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?

Our product has BLE and Zigbee at the moment. We want to add Matter. Ideally it would be multiprotocol but since you don't officially support that and our team is too small to really do a custom solution right now we will do two separate firmware images that the user can choose. So we will basically have a bootloader that can flash either version and before each DFU the user will choose which firmware to download. But to make it easy for us to actually support these two similar application we want to share most of the application code. Ideally the only difference will be the Matter/Zigbee comms library. My plan was to have one project with multiple build configurations that will conditionally compile either one of the libraries.

I used the custom board folder that now compiles as a target for building three separate images. I first manually changed my copy with your suggestions until I could compile that. After flashing that to the nRF54L15-DK it doesn't do anything. Flashing itself succeeds nicely but there are no leds blinking and nothing is printed over UART. Since I had modified the code as well I tried fixing that in various ways but got nowhere. 

Next I tried the one you sent back to me. That also compiles nicely (except for the issue with the build folder from Windows not working on Linux). I flashed that to the sake DK and it also did nothing.

Then I took a clean SDK 3.0.1 install and copied the Window Cover sample form there (using the VS tools from Nordic). I copied the board folder to that sample, added the partition manager thing and the bootloader overlay/conf. And that also compiled. And also failed to do anything.

Just to make sure it was an issue with the board I then took the last sample and selected the original target board (nrf54l15dk/nrf54l15/cpuapp) and that does work. Both the leds and UART have activity and I can add the example to Matter controllers. So I'm fairly sure the issue is with the board definition.

I have been on sick leave most of this week so I will try the board definition on a simpler sample early next week and let you know what that does. I really only started with this Matter sample as that is what I had experience with when I did the same thing in SDK 2.5..0 but it seems that over time this has become much more complicated.

Tiit

[AHaug]

Hi,

Tiit said:

I used the custom board folder that now compiles as a target for building three separate images. I first manually changed my copy with your suggestions until I could compile that. After flashing that to the nRF54L15-DK it doesn't do anything. Flashing itself succeeds nicely but there are no leds blinking and nothing is printed over UART. Since I had modified the code as well I tried fixing that in various ways but got nowhere. 

Next I tried the one you sent back to me. That also compiles nicely (except for the issue with the build folder from Windows not working on Linux). I flashed that to the sake DK and it also did nothing.

Then I took a clean SDK 3.0.1 install and copied the Window Cover sample form there (using the VS tools from Nordic). I copied the board folder to that sample, added the partition manager thing and the bootloader overlay/conf. And that also compiled. And also failed to do anything.

Just to make sure it was an issue with the board I then took the last sample and selected the original target board (nrf54l15dk/nrf54l15/cpuapp) and that does work.

Please correct me if I'm wrong. Until the last sentence, is this what you did:

Take the board files that I sent which are named (something like) blindyv3_nrf54l15_cpuapp which basically is a copy of the 54l15 DK and flash it to a nRF54L15DK and this did not work, but when building it with for nrf54l15dk/nrf54l15/cpuapp it compiled and ran on the 54L15DK everything worked?

If so, then that makes sense. The DK's won't run unless you've built the firmware for the DK, even though the custom board files are identical albeit with a different file name.

Tiit said:

I have been on sick leave most of this week so I will try the board definition on a simpler sample early next week and let you know what that does. I really only started with this Matter sample as that is what I had experience with when I did the same thing in SDK 2.5..0 but it seems that over time this has become much more complicated.

No worries, and I hope you feel better now. Yes please let me know

Kind regards,
Andreas

[Tiit]

AHaug said:

Please correct me if I'm wrong. Until the last sentence, is this what you did:

Take the board files that I sent which are named (something like) blindyv3_nrf54l15_cpuapp which basically is a copy of the 54l15 DK and flash it to a nRF54L15DK and this did not work, but when building it with for nrf54l15dk/nrf54l15/cpuapp it compiled and ran on the 54L15DK everything worked?

If so, then that makes sense. The DK's won't run unless you've built the firmware for the DK, even though the custom board files are identical albeit with a different file name.

Yes that is exactly what I did. But why would it not run if the board definition is identical? If that is the case how would I start developing a board definition for my own board? My plan was to take an example that works. Create my own board file for that and then run the example on the DK with my own board file. Then once that is working start changing the board file to match my own schematic and if something breaks I can still go back to the working example on the DK. 

Tiit

[AHaug]

Tiit said:

Yes that is exactly what I did. But why would it not run if the board definition is identical?

It is only identical if the file names also are identical

There are various items that may be hardcoded to be configured for usecases where a DK is built for. For instance, the ZMS configuration that we mentioned. It might be that they're picked up due to the SoC family that you define in one of the custom files, but it will still differ from the DK's board files since it uses a different name.  Some of those Konfigs can be seen here: 

 

In other words, there are things that you and I can't just assume will work unless you go through all of these files.

Tiit said:

I used the custom board folder that now compiles as a target for building three separate images. I first manually changed my copy with your suggestions until I could compile that. After flashing that to the nRF54L15-DK it doesn't do anything.

But if I were to guess, I would assume that the ROM offset config in the image above may be why your application does not start in the quote above

FYI, I'm not certain if I've linked this before or if you've seen it, but just to be sure https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-3-adding-custom-board-support/ 

Kind regards,
Andreas