Device Tree Configuration Guidelines

[Alan Jones]

Can Nordic provide general guidelines for manipulating the device tree configuration files for custom boards?

For instance, does the application require the exact same pin mapping as the SPM loader? If not, what if there are pin mappings for a UART during boot for instance, but the application disables the UART and repurposes those pins to GPIO in either the application device tree or the project's overlay file? Is the application required to use only a subset of the SPM peripherals? How are peripheral or pin conflicts resolved by the current build process which defaults to generating a merged hex file?

There also seem to be build issues with locating the out of tree board directory in the application directory, which would be preferable for simplifying application version control.

[Simon]

The SPM sample (ncs\nrf\samples\nrf9160\spm) does not map any pins. The only thing the SPM sample does is to set the security attribute of the peripherals (It also configures flash/ram as secure/non-secure, but this is not relevant for your question) listed in periph_cfg periph[] to either secure or secure (depending on the configurations in ncs/nrf/subsys/spm/Kconfig).

However, some peripherals does not work with a non-secure application (e.g. PWM0), due to their absence in Kconfig or spm.c. You will have to add it, as the customer did here.

Best regards,

Simon

[Steven]

OfflineAlan Jonesover 2 years ago

What about this though?

"Can Nordic provide general guidelines for manipulating the device tree configuration files for custom boards?"

Can you point me to any examples please?

[Steven]

To add to that, I'd say that 2.2 Walkthrough doesn't really demonstrate a custom board as you're only copying and pasting files from another demo. It doesn't say anything about adding additional functionality. Is that fair?

[Simon]

Steven said:

To add to that, I'd say that 2.2 Walkthrough doesn't really demonstrate a custom board as you're only copying and pasting files from another demo. It doesn't say anything about adding additional functionality. Is that fair?

That is correct. The 2.2 Walkthrough only shows how to create a new custom board folder, that you can use as a base for your specific board. It does not show how to add additional functionality to your board.

Would it be useful with a new section "2.3 Modify the board folder to your custom board"? Where I go through some different scenarios:

• If your board only has one button, connected to GPIO 30
  • Then you have to remove the other button instances, and change the GPIO of button1 to 30
• If you have an adxl362 device on you board, connected to some specific GPIOs
  • Then you could look at the board folder for the Thingy:91 to see how to add it to the board folder. Change the SPI instance if you want to use another, and select the pins according to how the adxl362 is connected.
  • Then you can build the adxl362 sample with your custom board name and it should work out of the box
  • (Be aware that this can also get added to an overlay file, but if the sensor is part of the custom board, the proper way is to add it to the dts board files)
• If you don't have an nrf52840 on your custom board
  • Here I demonstrate what should be removed. E.g. interface_to_nrf52840, nrf52840_reset++

Regarding the other comments, I'll forward it to the ones responsible for the blogs/tutorials.

Best regards,

Simon

[Steven]

Yes, certainly that would be helpful. My broader point is that the documentation is incomplete and that the application notes are essential, from a users perspective.

[Simon]

Thanks for your feedback, I'll forward it internally. I'll incorporate the mentioned section into the tutorial some time after easter.

[Simon]

I've forwarded your feedback to one of our tech writers. We aware that there is room for improvement in our getting started guides and are working on improving it.

[Henk Pragt]

Hi Simon,

I totally agree with Steven: the DTS is far too complicated to quickly start a custom design. Here's a thought: how about a simple wizzard where we can add a board name and tick some peripherals and I/O's from a menu, and have it create the DTS for us?

cheers,

Henk

[Simon]

Thanks for the feedback. I've forwarded your suggestion internally.

Best regards,

Simon

[Mike Austin (LPI)]

Sorry to rehash an older thread, but I stumbled across this after searching through the DevZone for some assistance on creating my own GPIO definitions in a .overlay file.

I won't bang on anymore than Steven has already about the challenges faced by newbies in navigating a lot of the stuff you need to learn to get up and running with NCS/Zephyr.

But I have what seems like a simple task - create my own GPIO pin reference in an overlay file that will enable me to turn a FET on or off so I can sample the battery voltage via an ADC input.  I'm using P0.30 for my GPIO pin to control the FET, and P0.02 as the ADC input for measuring the battery voltage.

This is what my overlay file looks like (it builds, but I've not yet tested it to ensure it works).  I've got to this point via a fair bit of trial and error, so if there is anything there that doesn't look 100% legit, please flag it up as I'll be honest - I've no real idea what I'm doing here!

/ {
	zephyr,user {
		io-channels = <&adc 0>;
	};


mypins {
    compatible = "gpio-keys";
    batteryen: batt_en {
        gpios = <&gpio0 30 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;
        label = "Battery Enable";
    };
};

};

A couple of questions:

1.  Will io-channels = <&adc 0>; actually ensure I am accessing AIN0/P0.02?  I'm basing this on what is already in the nRF52DK board file for the arduino_adc.

2. In my definition of the GPIO, what limits/restrictions/guidance is there in defining the references "batteryen", "batt_en".  And more importantly, what are they used for?

3.  In the DK board file, there are a bunch of aliases for the LEDs and buttons.  Why would I use an alias instead of referencing whatever value I have at "batteryen"?

I think its this level of support that is lacking in any documentation I've seen around Nordic devices.  Its like there is a certain level of competency you need to acquire in order to understand most of the info available, but getting to that point is akin to extracting the mythical "sword in the stone"

Cheers,

Mike

[Mike Austin (LPI)]

And then, how does this all come into the mix?  Is this an alternative to device tree overlay files?

Cheers,

Mike

[Sigurd Hellesvik]

Hi Mike,

Please create a new ticket for your new questions, to help us keep DevZone tidy.

You can link to this case in the new one as a reference.

Regards,
Sigurd Hellesvik