Custom nRF5340 Board in NCS

[WesC]

Last year i asked about a custom nRF5340 board when using NCS V1.7.0 and the comment was to just copy the entire nRF5340DK into my custom board folder and modify the names to match my board.

With V1.9.1 and VSC with the option to "Create a New Board" has there been any optimization in this method.

Is it still suggested to just create a folder and copy the DK board files or can i create a board through VSC for the nRF5340?

BTW.  I have tried using VSC with the nRF5340 and have been unsuccessful

[Elfving]

WesC said:

Sorry for the delay

Hehe yeah likewise.

WesC said:

but i changed my environment to just use NCS 1.9.1 and Toolchain 1.9.1

Gotya. From the log it looks like that didn't get updated completely.

WesC said:

if i make no modifications to the custom generated DTS file it will not compile because there are DT nodes with Aliases that are used in main.c

You can for instance run the button example on a custom 52840 board by copying contents of the nrf52840dk dts file. And you can run hello world on a default custom 5340 board. Getting the alias in the nrf5340 dts etc however is a bit more complex, as there are several files that needs to be renamed and modified. 

I believe this guide by Simon mentions everything you need to know though (see section 2.2), as well as what the different files are for. I just tried it myself along with the button example, and the build works fine. I haven't tried it in NCS 2.0 yet though.

Do the steps mentioned in the guide work for you?

Regards,

Elfving

[Martdur]

I've got the same compilation error. I add some lines to define sram0_shared and now it complies: 

/ {
	model = "XX";
	compatible = "XX,XX-v1-0-0";

    chosen {
        zephyr,sram = &sram0;
        zephyr,flash = &flash0;
        zephyr,code-partition = &slot0_partition;
        zephyr,ipc_shm = &sram0_shared; 
    };
	
    reserved-memory {
        #address-cells = <1>;
        #size-cells = <1>;
        ranges;


        //sram0_ns: image_ns@20000000 {
            /* Non-Secure image memory */
        //};
        sram0_shared: memory@20070000 {
            /* SRAM allocated to shared memory */
            reg = <0x20070000 0x10000>;
        };
    };
};

Hope that's helped.

[cldelahan]

I wanted to see if there has been any progress on this? My current solution is still to do what @MartKano recommended below, and simply add an empty block. 

This problem seems to be that after creating a new board of type nrf5340_cpuapp (nonsecure), there is an out-of-the-box issue with the device tree labeling. 

[Elfving]

Hello Conner,

I assumed this was somewhat taken care of in this case so I haven't looked into it further unfortunately. As this case is a bit old it might be preferable to create a new one. Though have a look at this webinar about this very topic coming out on Wednesday. It might be it will answer all your questions about it. 

Regards,

Elfving