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

[Edvin]

So one example of this is that there is no UART output on the coap_server sample, right?

Best regards,

Edvin

[Tiit]

Hi Edvin,

Yes. There is no UART output. 

[Edvin]

I see. There were no UART console in your board files. Sorry this took so long, but I needed to dig out why the DRIVER_HAS_SERIAL was not set, and it was the lacking settings in the board files.

Please see the attached project with it's boards folder:

7725.coap_server.zip

Warning: I do get an assert when running (stack overflow) but I didn't have time to look into the application why this was happening. I tested the same board files with the hello_world sample (NCS\zephyr\samples\hello_world), and that worked as intended. I don't know what other changes that may have been done to the coap_server sample.

Best regards,

Edvin

[Tiit]

Hi Edvin,

I see the serial output now so thank you for that. But I still don't understand why this is not working if the same sample built for the DK works. My board files are a direct copy of the DK board files so it should compile to an almost identical binary (just the board name is different). Even this UART change should not have been necessary as far as I understand. This overflow error now is another difference that makes me worried. The coap sample is rather simple (as is the hello world sample) and I do believe we can get those to work. But my end goal is the Matter window cover sample. That is a crazy complex sample that touches almost every part of the SOC system so these small differences will add up and this makes me worried that there will be hidden issues with the more complex sample. I really just want to port my own code that currently runs well on the 52840 to this new SOC. Right now it seems that this will be more difficult than going from a legacy 51822 project to a 52840 and Zephyr. I have done another project porting a 52840 based project to the new SDK3.0.1 and that went rather painlessly. So the issue really is just with the new 54 series SOCs. Maybe you can just make a simple custom board file using the 54L15 that would work with the Matter sample and post that somewhere. Seeing how many people seem to follow this post I'm not alone in having issues with this right now.

Tiit

[Tiit]

Hi Edvin,

I tried debugging the project you sent me. It seems to crash in thread setup. Specifically it fails in some crypto library function. In the OpenThread library there is crypto_psa.c. The function from that file called otPlatCryptoImportKey calls psa_import_key. That in turn calls psa_crypto_storage_store and that in turn calls trusted_storage_get_key. Eventually exection ends up in hw_unique_key_derive_key. It starts going through the cracen_key_derivation set of functions ending with cracen_key_derivation_output_bytes. But execution stops upon entering the cracen_key_derivation_output_bytes function with a USAGE FAULT. I'm not sure why this happens but it is very similar to the way the Matter samples fail with this board setup. This again confirms my suspicion that the root cause of all these problems is somehow related to Thread. All the samples I have tried that do not have Matter work with this board definition. The fact that UART also had issues is interesting but I don't think that is really related to the main issue.

Tiit