Migrating to NCS v2.0.0 "error: NRFX_TWI (defined at C:\NCS\v2.0.0\zephyr\modules\hal_nordic\nrfx\Kconfig:277"

[Ryjan]

I've been working on porting a project to NCS using VS Code as my IDE. Now that NSC v2.0.0 is out, I wanted to move to that. I found the migration guide: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/migration/migration_guide_1.x_to_2.x.html. I re-targeted the toolchain, and I found the scripts to change the include paths and pin control setup. That made that change over pretty painless; however, it did not fix an issue I was having with a TWI definition: "error: NRFX_TWI (defined at C:\NCS\v2.0.0\zephyr\modules\hal_nordic\nrfx\Kconfig:277"

It went on the state that "\build\modules\hal_nordic\nrfx\Kconfig:277 is assigned in a configuration file, but is not directly user-
configurable (has no prompt). It gets its value indirectly from other symbols. See
docs.zephyrproject.org/.../kconfig.html and/or look up NRFX_TWI in the
menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too."

I read some about those Kconfig files and compared the ones in v1.9.1 versus my new one in v2.0.0.

In v2.0.0 it looks like

config NRFX_TWI
	bool

In v1.9.1 it looks like

config NRFX_TWI
	bool "Enable TWI driver"
	depends on HAS_HW_NRF_TWI0 || HAS_HW_NRF_TWI1

The term "bool" without any value after it looks odd to me, but I'm still just learning how to understand these Kconfig files.I noticed that NRFX_TWIM is that same way along with several other entries. I tried copying the ones from v1.9.1 to v2.0.0 and it now objected to the NRFX_TWIM entry. So then I deleted it and it claimed I was over the memory boundary. I don't think that's a good fix. I couldn't find anyone else with the same problem.

Also, the link provided in the error "http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_NRFX_TWI" does not lead to valid search term. But when you take a "$" character off the end it show the values in the Kconfig file except for the ones with the empty "boot" terms.

Back to the issue, at this point I'm not sure where to look next. I doubt the Kconfig has an issue, but I'm still learning the basics of how that works.

[Ryjan]

I think I understand what I am looking for now, but I don't see it. The code I was upgrade from v1.9.1 to v2.0.0 is still having a problem with the I2C (TWI) settings and the PWM settings. Those were both update in a script to migrate them to the newer pinctrl overlay. That seems to be the source of my latest issues. Before, this line of code would set a PWM going:

		pwm_pin_set_usec(pwm_dev, DT_PROP(PWM_CTRL, ch1_pin), PWM_PER_US, OFF, flags);

DT_PROP() is giving me trouble here and where it was used for the I2C. It talks about accessing properties from the device tree in the the docs here, but with the new pinctrl setup is does not seem to address the change and the device tree does not seem to work the same. The macro seems to not work for this case. 'ch1_pin' doesn't exist. 'clock_frequency' does seem to for the I2C, but the pin and channel numbers do not seem accessible through the 'DT_PROP()' macro. Unfortunately, the documentation does not seem to address the change in how I2C, PWM and SPI properties are accessed as far as I can tell.

[Karl Ylvisaker]

Hello,

Thank you for your patience with this. The summer holidays have begun here in Norway, and thus DevZone is operating at reduced capacity. Apologies for any inconveniences this might cause.

You will need to make changes to the Device Tree according to the migration guide for the pinctrl migration documentation in order for this to work after the upgrade to NCS v2.0.0.
Could you possibly share your entire prj.conf and device tree? I could take a look to see if I spot where it is going wrong.

Please let me know if you would like me to change the ticket to private before you do any sharing - this will make it viewable by only yourself and the support engineers here at Nordic.

Best regards,
Karl

[Ryjan]

I might be missing something in the migration guide, but I have tried to follow it. I ran the script for spliting out the pincontrol in to a new .dtsi file. As of right now I have issues with the TWI and PWM modules, but when I bring the SPI online, I will expect to see issues there. My TWI issue shows up when I am displaying the pin numbers used by that peripheral, but I should be able to make it work. Before the switch to the pin control module, the DT_PROP() macro was used to get the attribute, in this case the pin numbers, from the board file.

As far as I understand it, the board file should be the source of truth for the pin setup. After running the provided update script according to the migration guide (pinctrl_nrf_migrate.py) a new *-pinctrl.dsti was created with the proper migration complete. In the switch to pin control, the DT_PROP()macro fails to recover the pin numbers. I can recover the set frequency because that still remained in the parent board .dts file. DT_PROP() does not appear to work for a pinctrl property. I haven't found instructions on how to accomplish it.

This becomes important when I have to run a recovery on the TWI bus for a particular encoder that we are using, It requires us to bit-bang the bus with a sequence to recover the device from a locked up mode. To run that I have to get the pin numbers.

The PWM module call "pwm_set()" requires a channel number which is also defined in the pinctrl module. We were using "DT_PROP(PWM_CTRL, ch0_pin)" to access that channel in v1.9.1, but that does not work because that property is deeper in the pincrl file rather than in the board device tree top level.

pwm_pin_set_usec(pwm_dev, DT_PROP(PWM_CTRL, ch0_pin), PWM_PER_US, SPEED2PULSE(speed), flags);

I'll go a head and include the requested code below:

prj.conf:

# Incresed stack due to settings API usage
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Logging
CONFIG_CONSOLE=y
CONFIG_LOG=y
CONFIG_LOG_PROCESS_THREAD=y
CONFIG_LOG_DEFAULT_LEVEL=4
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=y
CONFIG_PRINTK=y
CONFIG_LOG_PRINTK=y

# Segger RTT
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BUFFER_SIZE=15360
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=15360

# Random Number Generator
CONFIG_ENTROPY_GENERATOR=y
CONFIG_ENTROPY_NRF5_RNG=y
CONFIG_ENTROPY_NRF5_THR_POOL_SIZE=16
CONFIG_ENTROPY_NRF5_THR_THRESHOLD=6

# Flash NVS
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_NVS=y
CONFIG_NVS_LOG_LEVEL_DBG=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y

# Bluetooth
CONFIG_BT=y
CONFIG_BT_SETTINGS=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=n
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DIS=y
CONFIG_BT_DIS_PNP=n
CONFIG_BT_ATT_PREPARE_COUNT=5
CONFIG_BT_DEVICE_NAME="myLIFTER"
CONFIG_BT_DEVICE_APPEARANCE=1856
CONFIG_BT_DEVICE_NAME_DYNAMIC=n
CONFIG_BT_DIS_MODEL="project V0.1"
CONFIG_BT_DIS_SERIAL_NUMBER=y
CONFIG_BT_DIS_SERIAL_NUMBER_STR="10001"
CONFIG_BT_DIS_MANUF="company Inc"

# I2C
CONFIG_I2C=y
CONFIG_I2C_NRFX=y
# CONFIG_NRFX_TWI=y
# CONFIG_NRFX_TWI0=y
# CONFIG_NRFX_TWIM=y
# CONFIG_NRFX_TWIM0=y
CONFIG_I2C_LOG_LEVEL_DBG=y

# ADC
CONFIG_ADC=y
CONFIG_ADC_NRFX_SAADC=y
CONFIG_ADC_LOG_LEVEL_DBG=y

# PWM
CONFIG_PWM=y
CONFIG_PWM_LOG_LEVEL_INF=y

# SETTINGS
CONFIG_STACK_SENTINEL=y
CONFIG_SETTINGS=y
CONFIG_NEWLIB_LIBC=y

# BOOTLOADER
# Stuff I am experimenting with:
# nRF immutable secure bootloader
# CONFIG_SECURE_BOOT=y
# b0_CONF_FILE=prj_minimal.conf
# CONFIG_SB_SIGNING_KEY_FILE="priv.pem"
# For use without the private key that may be managed separately
# CONFIG_SB_SIGNING_CUSTOM=y
# CONFIG_SB_SIGNING_PUBLIC_KEY="/path/to/pub.pem"
# CONFIG_SB_SIGNING_COMMAND="my_command"

# MCUBOOT for OTA
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_IMG_MANAGER=y
CONFIG_IMG_ENABLE_IMAGE_CHECK=y

# BOOT_SIGNATURE_KEY_FILE ="${workspacefolder}/sec/sh_myl_key.pem"
# CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="${workspacefolder}/sec/sh_myl_key.pem"
# CONFIG_MCUMGR=y
# CONFIG_MCUMGR_CMD_OS_MGMT=y
# CONFIG_MCUMGR_CMD_IMG_MGMT=y
# CONFIG_MCUMGR_SMP_BT=y

board.dts:

/dts-v1/;
#include <nordic/nrf52832_qfaa.dtsi>
#include "board-pinctrl.dtsi"

/ {
	model = "project";
	compatible = "company,board";

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,uart-mcumgr = &uart0;
		zephyr,bt-mon-uart = &uart0;
		zephyr,bt-c2h-uart = &uart0;
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
	};

	leds {								/* added mot_en here for now need to find out how to define plain gpio output pin*/
		compatible = "gpio-leds";
		led0: led_0 {
			gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
			label = "LED_R";
		};		
		led1: led_1 {
			gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>;
			label = "LED_G";
		};
		moten: mot_en {
			gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
			label = "MOT_EN";
		};
	};

	buttons {
		compatible = "gpio-keys";
		button0: button_0 {
			gpios = <&gpio0 6 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Lim_SW1";
		};
		button1: button_1 {
			gpios = <&gpio0 7 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Bind_SW";
		};
		button2: button_2 {
			gpios = <&gpio0 18 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Lim_SW0";
		};
	};
	
	/*
	vsys0: vsys {
		compatible = "voltage-divider";
		status = "okay";
		label = "VIN_AN";
		io-channels = <&adc 1>, <&adc 2>, <&adc 3>;
		io-channel-names = "TEMP_AN", "I_MOT_AN", "VIN_AN";
		output-ohms = <2000>;
		full-ohms = <(6490 + 2000)>;
	};
	*/


	/* These aliases are provided for compatibility with samples */
	aliases {
		led0 = &led0;
		led1 = &led1;
		sw0 = &button0;
		sw1 = &button1;
		sw2 = &button2;
		bootloader-led0 = &led0;
		/*notes */
		ledr = &led0;
		ledg = &led1;
		limsw1 = &button0;
		bindsw = &button1;
		limsw0 = &button2;
		anin = &adc;
		pwm	= &pwm0;
		moten = &moten;

	};
};

&gpiote {
	compatible = "nordic,nrf-gpiote";
	status = "okay";
};

&gpio0 {
	status = "okay";
};

&adc {
	compatible = "nordic,nrf-saadc";
	status = "okay";
	io-channels = <&adc 1>, <&adc 2>, <&adc 3>;
	io-channel-names = "TEMP_AN", "I_MOT_AN", "VIN_AN";
};

&i2c0 {
	compatible = "nordic,nrf-twi";
	status = "okay";
	clock-frequency = < 400000 >;
	pinctrl-0 = <&i2c0_default>;
	pinctrl-1 = <&i2c0_sleep>;
	pinctrl-names = "default", "sleep";
};

&pwm0 {
	compatible = "nordic,nrf-pwm";
	status = "okay";
	pinctrl-0 = <&pwm0_default>;
	pinctrl-1 = <&pwm0_sleep>;
	pinctrl-names = "default", "sleep";
};

&spi1 {
	compatible = "nordic,nrf-spi";
	status = "okay";
	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
	pinctrl-0 = <&spi1_default>;
	pinctrl-1 = <&spi1_sleep>;
	pinctrl-names = "default", "sleep";
};

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0xc000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x32000>;
		};
		slot1_partition: partition@3e000 {
			label = "image-1";
			reg = <0x0003E000 0x32000>;
		};
		scratch_partition: partition@70000 {
			label = "image-scratch";
			reg = <0x00070000 0xa000>;
		};
		storage_partition: partition@7a000 {
			label = "storage";
			reg = <0x0007a000 0x00006000>;
		};		
	};
};

pinctrl.dtsi:

&pinctrl {
	i2c0_default: i2c0_default {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 8)>,
				<NRF_PSEL(TWIM_SCL, 0, 9)>;
		};
	};

	i2c0_sleep: i2c0_sleep {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 8)>,
				<NRF_PSEL(TWIM_SCL, 0, 9)>;
			low-power-enable;
		};
	};

	pwm0_default: pwm0_default {
		group1 {
			psels = <NRF_PSEL(PWM_OUT0, 0, 17)>,
				<NRF_PSEL(PWM_OUT1, 0, 16)>,
				<NRF_PSEL(PWM_OUT2, 0, 19)>;
		};
	};

	pwm0_sleep: pwm0_sleep {
		group1 {
			psels = <NRF_PSEL(PWM_OUT0, 0, 17)>,
				<NRF_PSEL(PWM_OUT1, 0, 16)>,
				<NRF_PSEL(PWM_OUT2, 0, 19)>;
			low-power-enable;
		};
	};

	spi1_default: spi1_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 12)>,
				<NRF_PSEL(SPIM_MOSI, 0, 10)>,
				<NRF_PSEL(SPIM_MISO, 0, 11)>;
		};
	};

	spi1_sleep: spi1_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 12)>,
				<NRF_PSEL(SPIM_MOSI, 0, 10)>,
				<NRF_PSEL(SPIM_MISO, 0, 11)>;
			low-power-enable;
		};
	};

};

You may note that in prj.conf I have commented out the "CONFIG_NRFX" TWI stuff and left in "CONFIG_I2C" stuff as that was causing a compile time issue that was discussed earlier in this ticket.

Thank you for looking into this for me, your help is much appreciated.

[Michal]

Hello,

I think that the easiest way would be to look at the blinky_pwm sample from NCS 2.0.0 should help (zephyr/samples/basic/blinky_pwm).

Also please look here for more information about the devicetree PWM implementation:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/build/dts/api/api.html#pwm

You will need to add a few lines to your board.dts file setting up your initial PWM configuration, like in the documentation above.
Please take a look for "pwm_led0" in zephyr/boards/arm/nrf52dk_nrf52832/nrf52dk_nrf52832.dts file.

Remember to also add an alias for that PWM node in board.dts file under aliases, for example
pwm_led0 = &pwm_led0;

If you do or extracting the channel number you can use
static const struct pwm_dt_spec pwm_led0 = PWM_DT_SPEC_GET(DT_ALIAS(pwm_led0));
and just follow the sample.

Hopefully that will solve the PWM issue.

Ryjan said:

My TWI issue shows up when I am displaying the pin numbers used by that peripheral, but I should be able to make it work.

So is the I2C/TWI issue only about extracting the pin numbers, or is there some bigger problem?

For extracting the pin numbers one way would be to use some functions from the TWI HAL:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrfx/drivers/twi/hal.html#c.nrf_twi_scl_pin_get
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrfx/drivers/twi/hal.html#c.nrf_twi_sda_pin_get
You can have a look for how it's done in the i2c_nrfx_twim_recover_bus() function in the latest Zephyr version:
https://github.com/zephyrproject-rtos/zephyr/blob/bdf3322de88fc4c1eb1950db28479d6367613498/drivers/i2c/i2c_nrfx_twim.c#L306

As for the original Kconfig issue, it should be enough to include

CONFIG_I2C=y
CONFIG_I2C_NRFX=y

Which I can see that you have done already.

Best regards,

Michal