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.

[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

[Ryjan]

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.

[Ryjan]

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?

 

[Michal]

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

[Ryjan]

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.