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]

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

[Tiit]

Hi Andreas,

I tried using the custom board to compile the Hello World sample and that seems to work. Now I'm not really sure how to proceed from this. I looked at the linked guide again and I think what I have so far is pretty close to that. Of course I have more files and more hardware defined but I think I need that if I ever want to actually compile a Matter sample using that board. 

It seems that my board definition is close to what it needs to be since I can get the Hello World sample working. I will try another sample that has FOTA included to see if that breaks anything. But to it seems to that there is a gap in the guides right now. There are guides on how to get a small custom board working with examples. And there are very complex samples with complex board definitions. But there is very little information on how to go from a small and simple board definition to a something that can support the complex Matter samples. 

You mentioned the ROM offset. How would I investigate this further? I tried searching for "ROM_START_OFFSET" and ROM OFFSET in Devzone but there are very few topics on that and I really don't know what this define even does. The most similar topic on Devzone suggested that adding the offset would fix an issue a user was having. So I tried with changing the offset default to both 0x800 and 0x0 but still nothing changed for me. 

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.

Tiit

[AHaug]

Tiit said:

You mentioned the ROM offset. How would I investigate this further?

You would have to investigate the board files within the SDK, for instance the defconfig file within the board foalder or search in the SDK for for instance "if BOARD_NRF54L15" and shee where unique pickups for the board are made.

The Matter samples may also have their own custom definitions for the nRF54L15, such as the settings backend (NVS vs ZMS) due to the memory type

Kind regards,
Andreas