General issues with overlays (ie, thingy53 board selected after build configuration nrf5340dk, is this normal?)

[aorion]

I am working through setting up device overlays and am struggling a bit. In some part because I can't find consistency in naming or location or anything. My goal is to set up i2s and use it. 

For example I went to kconfig and selected i2s to enable it, then went and found that in zephyr.dts, the i2s was disabled. I would have expected an error in the build if that were the case.

From a search it looks like this will require an overlay, which makes sense. I went to check where to stick this and found that my boards/ directory was populated entirely with incorrect board names, ie thingy53_nrf5340_cpuapp_ns.overlay, when I selected nrf5340dk_nrf5340_app as the board in the build configuration. Is this expected or normal?...

I thought to check against an install of the excellently detailed nrf_audio example. Unfortunately if you go into kconfig for that, i2s is disabled entirely, but the i2s in the overlay is "okay"! 

Does anyone have a concise checklist for what needs to happen to enable i2s, select the pins, and use it? I am about to just go dig into the registers themselves and give that a shot, it is at least very consistently documented in the 5340 peripheral guide...

[aorion]

Just to follow up as I have been doing additional debugging...

I'm still not sure why the nrf_audio doesn't have i2s enabled via kconfig. Looking for comprehension there.

What did help was I found this page -> https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/zephyr/hardware/pinctrl/index.html#state-model which elaborates on the new pinctrl method. In addition the project includes app.overlay which is a default, so the specific board name doesn't matter. The pinctrl can be created and assigned like the below

&pinctrl {

    compatible = "nordic,nrf-pinctrl";

    i2s0_default: i2s0_default {

        phandle = < 0x9 >;

        group1 {

            psels = <NRF_PSEL(I2S_SCK_M, 0, 4)>, <NRF_PSEL(I2S_LRCK_M, 0, 6)>, <NRF_PSEL(I2S_SDOUT, 0, 5)>;

            nordic,drive-mode = < NRF_PULL_UP >;

        };

    };

};

&i2s0 {

    pinctrl-0 = < &i2s0_default >;

    pinctrl-names = "default";

};

This builds but I am still unable to get status: "okay", it's still disabled. I don't see any logs or anything and am not sure what happens in the backend to make this work. If there is a misconfiguration I would have expected some kind of warning or error pointing out what is missing. As of right now I know that

1. The i2s device is enabled in kconfig (which, does that even matter?...)

2. The i2s device is in the zephyr.dts and matches the nrf_audio's zephyr.dts

3. The i2s device's pinctrl are in the dts as modified. In the same spot as the nrf_audio but with different pins.

4. The name of the device in the .c where I use device_get_binding matches the name of the i2s device (i2s0). 

Besides that, unless there is some dependency on another module that needs to be also included but is not, I am not sure where else to look, without any sort of error log. 

[Hieu]

Hi aorion,

What you described is abnormal, but it comes from a perfectly normal confusion which people new to Zephyr and/or nRF Connect SDK (NCS) would have . I had been through the same experience.

went to check where to stick this and found that my boards/ directory was populated entirely with incorrect board names, ie thingy53_nrf5340_cpuapp_ns.overlay, when I selected nrf5340dk_nrf5340_app as the board in the build configuration.

I assume you created an application based on some samples. On some of the samples in NCS, overlay files are required for some boards, so the samples include such overlays from the beginning.
You should be able to observe that when you first create the application folder, those overlays are already there, even before you created any build configuration. They come into effect when you run the build configuration for their target board.

Please note that some samples are also designed only for certain boards; and using a different one can sometime require major tweaking. You could read the sample's README to check which board support it.

---

Next, I observe that you are also confused why Kconfig is not updated when you update overlay. I believe that this is because you misunderstood Kconfig and device tree. Kconfig and device tree are not the same. You can read this article for more info: Devicetree versus Kconfig — Zephyr Project Documentation (nordicsemi.com)

May I suggest that you give that a read, and reevaluate your current situation to see if things make sense now, then come back here if you still have any questions?

Best regards,

Hieu

[aorion]

Hi Hieu,

Thank you for the quick response.

> You should be able to observe that when you first create the application folder, those overlays are already there, even before you created any build configuration

I actually re-created the project several times. I only see the build (and boards) folder after creating a build config. For example my i2s_example project, I have not created a build config since I just wanted the reference. It looks like this

> Please note that some samples are also designed only for certain boards; and using a different one can sometime require major tweaking. You could read the sample's README to check which board support it.

nrf5340dk_nrf5340_cpuapp is allowed under platform_allow. My concern was that it allows this but then all of the board files are listed as thingy53 after I build and the boards folder is created. Is this a bug? Am I going to run into issues with running a thingy53 DTS on a nrf53DK? i don't notice any issues so far, is it just a naming issue? For example as I understand, I should not be able to use RTT on Thingy53 but it is working fine. 

> Next, I observe that you are also confused why Kconfig is not updated when you update overlay. I believe that this is because you misunderstood Kconfig and device tree. Kconfig and device tree are not the same. You can read this article for more info: Devicetree versus Kconfig — Zephyr Project Documentation (nordicsemi.com)

I think I understand this now. From further reading it sounds like at one point kconfig was the way to do it. I was expecting something similar to rpi-config or makemenu (linux) to enable an already configured driver. It looks like it's added via the device overlay, which is fine, now that I know that the i2s checkbox in kconfig is not inconsistent. 

I did go through all of the documentation above and where I linked in the original reply. After providing the pinctrl and checking my overlays against the nrf_audio one, I am not able to see status: "okay" in my zephyr.dts (and the binding fails). Do you have any documents on how to troubleshoot this? The "Troubleshooting device trees" doc from Zephyr looks like it is more oriented toward device driver writers, not consumers. I am not modifying the driver I just need to see why it was not included (ie, am I missing config fields?...). I am in the process of reading through https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/build/dts/intro.html - however, a lot of this is pertaining to generated files, which I am not to that point yet. It's blocked from enabling I2S by something, where can I find information on what it needs to actually enable the device? For example, a log or a warning message or a checklist of criteria or anything? 

Thanks,

-Alex

[Hieu]

Hi Alex,

aorion said:

I actually re-created the project several times. I only see the build (and boards) folder after creating a build config. For example my i2s_example project, I have not created a build config since I just wanted the reference. It looks like this

Alright... That is indeed very strange. Could you please tell me what sample that is so I can take a look at it?

Also, how is your current development environment setup? PC OS? What method did you use to install everything?

aorion said:

Am I going to run into issues with running a thingy53 DTS on a nrf53DK? i don't notice any issues so far, is it just a naming issue? 

Yes and no depends on what you do with it. The chip is wired differently on the board, so I can't predict what issue you might run into.

aorion said:

For example as I understand, I should not be able to use RTT on Thingy53 but it is working fine. 

The problem with RTT and Thingy53 is probably just that the Thingy53 does not physically have a debugger. If you provide an external debugger to it, RTT will work just fine. That is the reason RTT comes up. So, your setup might still be for the Thingy.

aorion said:

It looks like it's added via the device overlay, which is fine, now that I know that the i2s checkbox in kconfig is not inconsistent. 

aorion said:

From further reading it sounds like at one point kconfig was the way to do it. I was expecting something similar to rpi-config or makemenu (linux) to enable an already configured driver. It looks like it's added via the device overlay, which is fine,

I would like to elaborate a little since there seem to still be some misunderstanding here. (Sorry if that is not the case)

The checkboxes you mentioned are probably from the GUI Kconfig in nRF Connect VS Code Extension? The GUI provides a ... GUI to configure Kconfig. It also provides some conveniences like for example: checking dependencies.
When an option is greyed out, it usually means that a dependency is not met. However, CONFIG_I2S should not have any dependency. I will look into it when I try to follow your step.
Ultimately, Kconfig will save the changes to .conf files in the project. Most of the times this is proj.conf..Next, Kconfig is used to configure mostly software related feature. For example, to enable GPIO features you almost always need CONFIG_GPIO=y. Only then can you call functions like gpio_pin_toggle();

Devicetree on the other hand describe the hardware availability. For example, to use UART1 peripheral, you need to set it with status="okay" in DTS or overlay files. Otherwise, UART1 related software functions, including Kconfig, would not work or would result in a build error.

With that, we arrive at:

aorion said:

I am not able to see status: "okay" in my zephyr.dts (and the binding fails).

Not sure what you meant by the binding fails. Have you set status to "okay" in your overlay file?

I have not used I2S myself, but from my experience with other peripherals, you probably will need to enable it both in Devicetree (via overlays or custom board files) and Kconfig.

You can refer to this sample to see how I2S can be enabled: I2S Echo Sample — Zephyr Project Documentation (nordicsemi.com)
While you try out this sample, please also check if you still have a boards folder generated with all the thingy53 overlays like you were having.

In the sample, you can see I2S is enabled in the overlay file as followed:

// The original sample did not turn off SPI4, which is configured 
// to the same pins i2s is being configured to.
// Therefore, here spi4 is explicitly turned off to avoid warnings
&spi4 {
	status = "disabled";
};

&clock {
	hfclkaudio-frequency = <11289600>;
};

i2s_rxtx: &i2s0 {
	status = "okay";
	pinctrl-0 = <&i2s0_default_alt>;
	pinctrl-names = "default";
	clock-source = "ACLK";
};

That will result in the final zephyr.dts having this line:

			i2s0: i2s_rxtx: i2s@28000 {
				compatible = "nordic,nrf-i2s";
				#address-cells = < 0x1 >;
				#size-cells = < 0x0 >;
				reg = < 0x28000 0x1000 >;
				interrupts = < 0x28 0x1 >;
				status = "okay";
				pinctrl-0 = < &i2s0_default_alt >;
				pinctrl-names = "default";
				clock-source = "ACLK";
			};

And you can see the I2S software driver/library is enabled in Kconfig in proj.conf as followed:

CONFIG_I2S=y

Once again, you need both Devicetree configuration and Kconfig for things to work. In your case, you need to both update overlay and Kconfig. Please try out the sample to see it working first.

Best regards,

Hieu

[aorion]

Hi Hieu, 

Thank you for your patience. 

I am using PC, Windows 10, and I installed everything using the getting started guide (ie, Toolchain -> Install -> Run VS Code). VS Code is 1.72.2. I am running the peripheral_uart sample using the nrf5340 DK as a base. 

I did go add the i2s echo example from the zephyr SDK (which btw, i2s_example is not the same, i2s_example is apparently outdated in several respects). After adding the same build configuration I get the expected overlay files for nrf5340dk. I don't see what I have done differently between the two. Only peripheral_uart sets up the thingy53 overlays instead. 

> The checkboxes you mentioned are probably from the GUI Kconfig in nRF Connect VS Code Extension? The GUI provides a ... GUI to configure Kconfig. It also provides some conveniences like for example: checking dependencies.

I can understand the frustration. I feel like I am working from basic principles here. Click a checkbox, and the options in the project should be enabled. What I don't know is how to actually confirm that these things are enabled. Knowing what you mentioned about prj.conf and CONFIG_I2S=y, I can confirm that selecting I2S bus in kconfig and rebuilding does not add CONFIG_I2S to my prj.conf. In addition I needed to add CONFIG_I2S_NRFX as well. Once I did that, it compiled just fine. In addition the device tree binding is outdated. 

Using these troubleshooting steps I was able to get the project compiled and flashed. I am still working through some issues (ie, I only get one transmission and the data out doesn't reflect the buffer) but it's a start.