I'm trying to duplicate the boot behavior of a Thingy91 on a custom board, i.e. SW4:BOOT and SW3:BUTTON on power up, but the switches available use different IO. I'm wondering where and how to modify the configuration.
Thanks,
JT
I'm trying to duplicate the boot behavior of a Thingy91 on a custom board, i.e. SW4:BOOT and SW3:BUTTON on power up, but the switches available use different IO. I'm wondering where and how to modify the configuration.
Thanks,
JT
Hello John,
Are you writing your application with a basis or dependency on Nordic Semi's sdk-nrf code base? I may not be developing with the most commonly used set of tools (Linux command line, Python, west, cmake and the 'set up manually' stuff). But this has given me an insight early on to the Device Tree Source or 'dts' files for Zephyr supported boards. Are you familiar with the dts files for the Thingy91_nrf9160? In my build environment I find these files in [west_workspace]/nrf/boards/arm/thingy91_nrf9160.
There are several files in this Nordic board provided directory, both dts and Kconfig files, and a couple more. Can be a little overwhelming, but one thing I have learned is that a larger or 'parent' .dts file can have just small parts amended to it, or over-written, by creating a file in your application's area, with the extension ".overlay".
Forgive me if I offer info you already know. Dot overlay files are themselves written in Device Tree Source. I've managed to achieve changes simple as moving one I/O pin assignment over, or change the sample app's default I2C clock rate on a particular I2C peripheral instance, by creating along side my app sources a directory named `boards`, and within it a file named `thingy91_nrf9160.overlay`.
If by chance your application requires you to build in a non-secure way -- several Nordic sample apps require this -- you will want to create a file with your board name followed by 'ns' in the basename, e.g.: `thingy91_nrf9160ns.overlay`. DTS files have a syntax for including other .dts and .overlay files, so when you have a pin assignment or other hardware change you would like to effect in both secure and non-secure board configurations, you can create a file with a basename of your choosing, and have the board-name-specific overlays include the common one. There is already an example of this practice in Nordic Semi sdk-nrf v1.6.1 `nrf/boards/arm/thingy91_nrf9160` directory.
I think I shared this Nordic Youtube video tutorial link in a prior post where I had questions, but this gave me some good initial understanding and help on which questions to ask next:
* www.youtube.com/watch?v=sWaxQyIgEBY
I happen to be developing with Zephyr RTOS' 2.6.0 release, not the cutting edge, so this documentation at the Zephyr Project site has also helped me grasp how to connect more traditional C code with device tree nodes:
* https://docs.zephyrproject.org/2.6.0/reference/devicetree/api.html
Still working to wrap my mind around these programming languages and Zephyr design features -- DTS and Kconfig -- but am also now able to build some stuff beyond the basics. If I can do so there must be hope!
- Ted
Hi Ted,
Thanks for the detailed response. I'll read through it later today in detail and certainly have a look at the videos.
I did find what I was looking for in this directory, "C:\ncs\v1.7.1\bootloader\mcuboot\boot\zephyr\boards".
There are configuration files for each of the MCU used on the Thingy91 ("thingy91_nrf52840.conf" and "thingy91_nrf9160.conf") and within each is a section that defines the serial recovery GPIO, level etc.. In this case I have a Button attached to SIO_39 on the nRF52840 that pulls the line low when pressed.
-----
# MCUboot serial recovery
CONFIG_GPIO=y
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_DETECT_PORT="GPIO_1"
CONFIG_BOOT_SERIAL_DETECT_PIN=7
CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=0
-----
I'm also using Segger as a development environment and the settings are accessible through the "mcuboot_menuconfig" configuration menu.
JT
Good morning John,
Thank you for sharing the nRF52840 and 9160 dot conf files. On review I have copies of those as well, as part of Nordic's sdk-nrf v1.6.1. And pretty much in the same path starting at my Nordic SDK `west` workspace root directory.
This is very interesting to me to see such hardware specific defines in a Kconfig file. There are references to specific pins, which I'm not accustomed to see in Kconfig files. Now you have me curious to see how mcuboot is using these options, and why (at least the named pin) is not in a dts file for this project or board?
Are you already somewhat familiar with the languages / paradigms of Kconfig and Device Tree Source? In my reading and use so far I find that device tree files are specifically for describing hardware arrangements, largely the resources and on-chip peripherals of a given microcontroller, SoC or SiP. Our DTS files are at build time quickly (or early) converted by `dtc` to C sources, which are then compiled by gcc or crosstool-ng or similar in the more traditional compilation sense.
Kconfig in contrast provides high level and finely granular ways of enabling more programmatic things in a project. There are often many hardware references in a project's Kconfig files. For example, I must ensure in my prj.conf file that CONFIG_I2C=y is present, to enable Zephyr RTOS' in-tree I2C driver and subsystem. But this reference to I2C does not know any details about which I2C peripheral(s) I enable elsewhere in device tree and / or dot overlay files. Kconfig does not generally know or care about the pin assignments or other hardware details, but rather just the code base to support those given peripherals.
Kconfig as you may know can enable a lot of things that are not hardware: floating point and complex math libraries, printk and printf family functions, and third party libraries which are designed with Kconfig written among their library sources.
Device Tree Source is in a manner somewhat hardware agnostic too: DTS supports pretty much all microcontroller architectures for which there are developers willing to write DTS files. The details of going from device tree source to controller-specific-C-code are, I believe, captured in the hardware abstraction layer (HAL) sources which many chip and SoC makers provide.
Regarding that video on device tree, the recorded class given by Marti Bolivar, at around the28 minute mark there is a key example of device tree source flexiblity. Mr. Bolivar is teaching with a sample Nordic app which involves an I2C/SPI ready sensor. He builds the project with a particular I2C peripheral enabled in his device tree file. He demos that code. Then he changes just a couple of device tree lines to make that DTS "node" point to the target microcontroller's SPI peripheral, with one and the same map-able GPIOS now carrying SPI signals. He rebuilds the project -- without changing any C code -- and now the sensor is communicating via SPI. Pretty slick!
Granted, one has to know a good amount to set up a project both in hardware and software to enjoy this kind of flexibility. But so far I really like how Device Tree Source goes so far to encapsulate hardware specifics. This makes a project's C code cleaner and more portable, at least to the extent that a developer cares about these coding practices.
So your posted question caught my eye because I was just here a couple months ago, with the same question. I got some good help from Devzone (also community forum at Jared Wolff's embedded development site). I am also on the cusp of writing device tree files for a custom board myself. So far I have just done the more modest .overlay files to amend and tweak already supported dev boards. I think however that device tree source (its own project too - https://www.devicetree.org/) will be your friend in situations where you must modify button, GPIO and related hardware configurations.
Sorry to be long winded, John! Keep safe,
- Ted
Hi Ted,
I'm really just beginning to work with Zephyr but I am developing an appreciation for it's flexibility. The video (Marti Bolivar) was quite helpful and the specific segment on I2C/SPI was a bit of a watershed moment for understanding the philosophy behind the approach. My board uses an SPI device that's also on the THINGY91 so now I'm looking forward to bringing up instead of dreading it.
On MCUBoot; Originally, I was expecting to find a unique device tree file for MCUBoot but since it's meant to be independent of the operating system having some other form of hardware definition is understandable. One thing I thought might have been configurable specifically for MCUBoot would be the UART but it does take that definition from the DTS file for the board.
JT
