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.

[gerardmarull]

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

[Ryjan]

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.

[yoyou]

Hi

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