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 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

[Edvin]

So the issue is that there is no output?

Tiit said:

It also fails to run the coap_server sample in exactly the same way (no output but no errors on compiling/flashing).

I noticed this in the build log:

warning: UART_CONSOLE (defined at drivers/console/Kconfig:42) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: SERIAL_HAS_DRIVER (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_UART_CONSOLE and/or look up UART_CONSOLE in
the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration
Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

Is that what you are trying to work out? Or do you mean that the application is not working as it should (something about Thread or the radio, or something)?

Best regards,

Edvin

[Tiit]

Hi Edvin,

That is not the issue I'm working on. I'm not sure why that happens. But even if this were the reason it would still be puzzling why identical board definitions would break in some samples and not in others. UART output works for this custom board in some samples. The samples that fail seem to fail completely as nothing is happening on the DK leds as well.

Tiit