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
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
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
