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'm sorry for being so helpless with this. 

So I tried searching for "if BOARD_NRF54L15" in the whole 3.0.1 SDK I have. The only matches I found are either in the DK board directory (and I have these in my board files as well, I checked) and in the Matter samples directory (of which I guess only the Window Cover samples is important). The one in the sample directory should only apply to _NS builds which I don't care about for now. So this is still something different. There are a lot of references to "NRF54L" but those should already apply as my board should also select the correct SOC version and that would match all those instances where needed.

I'm actually not sure why the ZMS thing would be needed for my board overlay to be honest. Because after this search of the SDK I did not see where it would be set for the DK and not set for a custom board. This is all very confusing.

Tiit

[AHaug]

No worries, and sorry for not being more helpful/clear.

The ZMS thing is just an example I'm bringing up as things that you need to look for w.r.t what you might be missing. You can set it up through configurations instead. The Matter samples simply automatically include ZMS for that build target since ZMS is better than NVS is for RRAM.

If you find anything that depends on the 54l15dk board target that you try to port to your custom board based on the 54l15dk then you need to add that so that the sample compiles to exclude what the root cause may be.

Did you have any luck with compiling any other samples that were more complex than the Hello World sample, but less complex than the Matter samples?

Tiit said:

I hope you can suggest what else I can try. While waiting for your reply I will try to compile different samples for that board and see where it works and where is breaks - maybe that will give a clue as to what could be the issue.

The second part we need to move any further is to investigate where it hangs and for what reasons it hangs i.e logging and debugging. I know you said that your device hangs without booting the application, but we should be able to find out where if you enter a debug session and some breakpoints 

Kind regards,
Andreas

[Tiit]

Hi Andreas,

I have tried this board configuration with quite a few samples now and have found no problems so far. I have tried the BLE LBS sample and also the Zephyr MCUboot sample. These should exercise the same types of hardware as the Matter sample. I also tried more simple examples and they all also work as expected. My next step is to try to find a sample with Thread. I have not tried the other Matter samples yet but I will also try those as soon as possible. I was sure the MCUBoot sample would fail as that would also have all those offset issues, right?

I will also try the debugger as you suggested. I have another issue in another support thread here as well and it takes me a while to switch between these two issues unfortunately as I have to install and uninstall the SDK and build systems all the time. I apologize for taking time to get back to you.

I also tried to find where in the SDK ZMS is activated for the nRF54L15 DK and the Matter sample and I could not find that. I really hope this is not done somewhere in the toolchain. I'm currently using SDK and toolchain versions that match but as far as I've seen there are tons of projects where SDK and toolchain versions are not in sync and this would cause all kinds of bad things for those. You gave the ZMS as an example of something that is done differently for the DK from customs boards but can you please show where this gets tacked onto the DK builds (and not to custom boards)? I'm having trouble finding any place where this would get added to DK builds and not to custom boards.

Tiit

[Tiit]

Hi again,

I tried the coap_server sample as that should use Thread and not much else. So my guess is it should run on all the Nordic DK-s. ANd I tried compiling it with no changes for the nRF52840-DK where it does work (blinking led when a button is pressed and printing out something over serial), Building the same thing for the nRF54L15-DK succeeds but after flashing the DK does nothing again. Is that sample supposed to work on that DK? There are no DK specific files in that sample so it should just use the standard DK setup I guess. Many other samples also did not have a specific setup for the DK but still worked. The only thing that sample sets in the overlay for the 52840 DK is selecting a different RNG which should not really matter, right?

Am I correct to deduce from this that the issue is with Thread on the nRF54L board? Can you also try compiling the coap_server sample for the 54L15 and see if that works for you? Maybe there is an issue with my hardware? The weird thing is that the matter sample built for the DK still works but built using the custom board that should now be identical to the DK configuration (except for name) fails to run.

Tiit

[Edvin]

Hello Tiit,

I am sorry for the late reply. Andreas is currently out of office, and he will be for a few weeks. We are working on a large backlog (in tech support, not from Andreas), and hence, since this is a fairly long thread. Is it possible for you to summarize the current situation, and what you need from me in one post? Thank you for understanding, and I am sorry for the inconvenience!

Best regards,

Edvin

[Tiit]

Hi Edvin,

No problem at all. I will try to summarize and update the current situation here briefly.

What I'm trying to do here is port my existing project from SDK 2.6.0 to 3.0.1. The reason for that is that we are trying to move from nRF52840 to nRF54L15 for the bigger memory and better price. Our project is a Matter Window Cover and based mostly on the sample form the SDK. Since board definitions changed a lot between 2.6.0 and 3.0.1 I need to define a new board in 3.0.1.

To begin I started like I did in 2.6.0. I took the Matter Window Cover sample in 3.0.1 and created a new project from that. I compiled it for the nRF54L15-DK and tested it all works. Then I used the VSCode plugin to create a new board for that project in the project folder. This makes a barebones board that this sample does not compile for. My next step was to make my new board identical to the DK board definition (keeping the new folder and board name). My thinking was that I can then test that the new board compiles and works at least on the DK and I can start changing that into my custom board. But this is where things went wrong. We have managed to get the project to at least compile and flash with this new board definition now but it still crashes somewhere I think. The same board definition works without changes for most of the other samples (BLE, Blinky, MCUBoot...) but fails for the Matter Window Cover sample. It also fails to run the coap_server sample in exactly the same way (no output but no errors on compiling/flashing). My guess is this has something to do with Thread because both of the failing samples use Thread.

Just yesterday I tried the Matter Window Cover sample with a board ported from 2.4.0 and that works. But that also has the nRF52840 SOC. So I think the issue is specifically with nRF54L15 and Thread. I have not tried debugging this with the debugger yet as that also seems to have some problems for me on Ubuntu and VSCode right now.

The board definition folder should be attached to this ticket already. You can try the sample with the 3.0.1 samples to recreate the issue.

Tiit

[Edvin]

So the board files that you are talking about, is it the sama.zip from this reply?

And just to be clear, you are saying that you are able to reproduce the issue that you are seeing running on an nRF54L15DK, using your board files, running the coap_server sample in NCS v3.0.1?

Best regards,

Edvin

[Tiit]

The board files in 6661.wc.zip are what Andreas sent me and I used those. But I'm fairly sure the issue would happen with any of the files linked here.

Edvin said:

And just to be clear, you are saying that you are able to reproduce the issue that you are seeing running on an nRF54L15DK, using your board files, running the coap_server sample in NCS v3.0.1?

Yes. And my board files should define all the hardware identically to the DK board definition. 

Tiit