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

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

yoyou — Fri, 05 Aug 2022 02:46:47 GMT

in NCS1.9.99-, get note pin number from follow line:

#define I2S_MCK_PIN DT_PROP(DT_NODELABEL(i2s0), mck_pin)

how to get pin number in NCS2.0.2?

Best regards

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

Ryjan — Wed, 20 Jul 2022 20:16:01 GMT

I'll need to watch that again. There's a lot of information. I'm glad to see that I'm not just being critical when I think that the documentation and examples provided are sparse. Another thing is it seems like there are about 5 or 6 ways things can be done and most of my searches show a different approach. I was handed this project a few weeks ago where it already ran, but I needed to format the repo so it's not 5GB on our git hub account. V2.0.0 splits the SDK files from the toolchain and I'm hoping has some improvements with relative paths (which is quite handy for deploying a repo on another machine). This issue and another I am having with getting the MCUboot signing and versioning seem very straightforward and seem like the transition should be simple, but the bits I am able to find are all done from a kconfig/device tree or as a command line input or in the CMakeLists or in a prj.conf or in an overlay. It makes sense that they are accomplishing the same thing, since it all boils down to different commands in a script. If I was starting from a simple project from the ground up I'd just pick a method, but the project worked fine in V1.9.1, with the exception on the bootloader stuff, but in he transition to V2.0.0 the new pin control fails to work. There is a deeper incompatibility with the way it was setup that the migrations guide does not seem to address. The migration guide's example doesn't give a full picture of before and after. It assumes I have the device tree setup in slightly different way. I'm going to continue digging deeper. I can see the power in this device tree setup, but it's a lot to master still.

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

gerardmarull — Wed, 20 Jul 2022 07:41:16 GMT

Regarding PWM issues, it looks like you are creating DT nodes without any compatible. You need to create one so that DT parser knows what "pwms" contains. You can also make use of the special zephyr,user node, which operates without compatibles (useful for quick samples).

I'd suggest watching https://www.youtube.com/watch?v=o-f2qCd2AXo where you'll actually find a driver using PWM. You'll find links to the source code in the video.

You can also look at this recently updated set of samples upstream: github.com/.../bbc_microbit

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

Ryjan — Fri, 15 Jul 2022 16:40:27 GMT

I tried implement your suggestions.

I placed it in a root node just by adding the "/{}; around the 3 channel definitions. I have errors where is wants a compatibility binding. I think that it is misinterpreting what these definitions are. The macro seems to be broken by this misinterpretation since the that's where the compiler fails and the string it makes looks like the ending concatenation is not correct. It' looks like this: '__device_dts_ord_DT_N_S_pwm_motor_lead_0_P_pwms_IDX_0_PH_ORD' and I think that "IDX_0_PH_ORD" is likely not expanding correctly because it's not interpreting the entries in the device tree correctly.

I inspect the example you suggested and it looked like there is a top section where the root is shown and the pwm_led0 is a part of that, so I moved my pwm channel definitions into that scope and ran into the same issues where it wants a compatible binding. I did try "nordic,nrf-pwm" and it did not like that.

I've looked for answers to my above-mentioned assumptions in above attached documents but I did not find it there.

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

Michal — Fri, 15 Jul 2022 09:27:06 GMT

Hello,

I think that the "Property not mentioned in "/"" error is that you are supposed to put in in a root node.

So if you don't have one, try
/ {
{all your pwm_m nodes}
};

Take a look where the pwm_led0 is defined in zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts

Here is a mention of root nodes:
developer.nordicsemi.com/.../intro.html

Best regards,
Michal

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

Ryjan — Thu, 14 Jul 2022 17:45:09 GMT

I've been trying to fix my device tree files to be like the examples in the migration guide, but I get a compiler error.

Here is the guide: PWM migration

It does not mention pin-control but the format looks correct from what I understand. Since it does not mention pin-control, it does not specify where the code goes so I made the assumption that the default and sleep setting are the only part that ends up in the pin-control module and the new node (which are referred to as "definitions" in the migration guide, but use the macro "DT_NODE_LABEL" to retrieve, but in the PWM developer guide they are called "node_id"). SO I am assuming that they are all the same thing. My code ends up looking like this:

board pinctrl.dtsi:

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

board.dts:

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

pwm_m0: pwm_motor_lead_0 {
	pwms = <&pwm0 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
};

pwm_m1: pwm_motor_lead_1 {
	pwms = <&pwm0 1 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
};

pwm_m2: pwm_motor_lock {
	pwms = <&pwm0 2 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
};

Once again I have made several assumptions. In the in the section of the developer guide for the PWM it shows single node with multiple entries, and the migration guide shows multiple definitions with single entries. Assuming that these are the same, I chose the latter so I can access the channel using DT_NODELABEL(pwm_m0). I've made the assumption that the pin-control keyword "PWM_OUT0" links to "0" in the definition pwms = <&pwm0 0 PWM_POLARITY_NORMAL>. That what it looks like in the migration guide, though it does not explicitly say that. But at this point it still fails to compile. VS Code underlines each instance of "pwms" with the message 'Property not mentioned in "/"'. I'm not sure what to make of that error, but the compiler fails out on my definition "pwm_motor_lead_0" which is the line just above the first "pwms =<..." definition statement.

Are my assumptions correct? and what have I still done wrong?

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

Ryjan — Wed, 13 Jul 2022 21:31:08 GMT

Unfortunately this has not yet solved the issue. I2C still has a compiler error somewhere buried deep in a macro. If I am understanding how the pin-control module works nothing so far has addressed that issue. The examples shown, even for the PWM Blinky v2.0.0 still jut use the legacy device tree without the pin-control module, as far as I understand it. I'm trying to move to the new system. It worked fine before I moved to pin-control. I looked at the examples Michal listed and tried to implement them, but in the end when I looked deeper at the examples I saw that they were not using pin-control. I've looked through the pin_control.h header file to find some suitable macros, but I could not find them there.

I've looked at this before: Migration of PWM. I'm going to dive deeper into this. I did see a previous attempt of mine that had the "PWM_DT_SPEC_GET" commented out. Now that I'm a lot more familiar with this I see where it talked about changing a in number out for a channel number. I don't see a way to specify a channel for the PWM.

For the time being, I'm going to roll back to the non pin-control setup to continue development.

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

Michal — Wed, 13 Jul 2022 13:24:45 GMT

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.

[quote user="titan vista"]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. [/quote]

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

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

Ryjan — Tue, 12 Jul 2022 15:12:17 GMT

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.

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

Karl Ylvisaker — Tue, 12 Jul 2022 13:17:02 GMT

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

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

Ryjan — Wed, 06 Jul 2022 19:36:14 GMT

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.

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

Ryjan — Fri, 01 Jul 2022 15:39:33 GMT

It looks like this project had both CONFIG_I2C and CONFIG_NRFX_TWI equaling 'y' and I suppose that led to a conflict that was not present in sdk versions older than 2.0.0. I commented out all the NRFX stuff:

# 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

I still haven't gotten it to compile since the macro "DT_PROP" appears to use "DT_CAT" to concatenate some stuff to get the identifier for the i2c channel pin. That must have changed between the Zephyr usage and the NRFX usage. I'm digging to find out how to use something else in it's place, but it looks like you've got me on the right track.

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

Øivind — Fri, 01 Jul 2022 11:17:25 GMT

Hi,

If you were using CONFIG_NRFX_TWI, try using CONFIG_NRFX_TWI1 for example instead, replacing the number with the instance of i2c you are using. This is specifically if you are not using the Zephyr API. When using the Zephyr API just use CONFIG_I2C.