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

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

Hieu — Fri, 04 Nov 2022 09:08:37 GMT

Hi Alex,

No worries. I am unfamiliar with I2S specifically so I cannot give any advice about it.

DeviceTree should be somewhat more straightforward than Kconfig. I hope you have understood it now.

Kconfig can be complicated and confusing. There is one more resource I would like to recommend:
Build System (CMake) — Zephyr Project Documentation (nordicsemi.com)

If you ever have any further trouble, Kconfig or things just not working like it should, please feel free to open another Q&A. The community and we at Nordic will be sure to help you :D

Best regards,

Hieu

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

aorion — Fri, 04 Nov 2022 06:38:51 GMT

Hi,

Sorry for the delay, just wanted to say thanks for the resources, those are a good reference. Generally I have been going through the zephyr documentation, the sample projects, etc. which has some of the same material but is, like you said, not all for the same board, and some of it was outdated.

The reason I posted originally is because I was (still am...) seeing legitimately confusing results from setup and kconfig operations with regards to what boards are referenced. Since the actual issues were unrelated and the project still seems to be compiling and running OK, I verified the answer and will continue to reference those pages.

Thanks,

-Alex

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

Hieu — Wed, 26 Oct 2022 20:28:49 GMT

Hi Alex,

[quote user="aorion"]I can understand the frustration. I feel like I am working from basic principles here[/quote]

Hey, don't feel bad. I too couldn't make any heads or tails out of this before I ask people who know. From what people tell me, a lot of them also share the experience. It is quite a complicated thing to get into.

I should have told you that we have this DevAcademy site in my earlier replies. Sorry about that.
This site has a tutorial course to get you accustomed to the nRF Connect SDK. Here is a link to the that course: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/

[quote user="aorion"]

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

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.

[/quote]

Unfortunately, I cannot reproduce your observation with both NCS v1.9.1 and NCS v2.1.0.
For both versions, I see the "boards" folder appear right away, containing the overlay files for the Thingy53.
This is also the expectation, as it is how the sample is setup.

What version are you using?
Also, please check your <Build Config Folder>/CMakeCache.txt, search for DTC_OVERLAY_FILE, and see if your nrf5340 DK build configuration actually picks up the Thingy53 overlay file like you fear.

[quote user="aorion"](which btw, i2s_example is not the same, i2s_example is apparently outdated in several respects)[/quote]

I can't comment on this. I initially looked at the I2S Example as well, but upon seeing just short note referring to the LiteX VexRiscv I moved away from it, since I feel it might not be meant for nRF DKs.

[quote user="aorion"]selecting I2S bus in kconfig and rebuilding does not add CONFIG_I2S to my prj.conf[/quote]

Have you clicked on the "Save to File" button?
Clicking "Save" only save the change to the <Build Config Folder>/zephyr/.config file. It will still affect your final build output, just not the prj.conf file.
To save the changes to prj.conf to use across all build configurations, you need to use the "Save to File" button.

[quote user="aorion"]In addition I needed to add CONFIG_I2S_NRFX as well. Once I did that, it compiled just fine.[/quote]

Are we still talking about the I2S Echo sample, unmodified? Or did you add some custom behavior? I compiled the I2S Echo sample just fine using the configuration as is.

[quote user="aorion"]In addition the device tree binding is outdated. [/quote]

Could you please elaborate on this?

All in all, I feel like we are moving in a good direction, yes?
You might feel like saving time by just pushing forward now, but I still recommend taking a step back and go over these resources first.
- DevAcademy course mentioned above for some warm-up.
- Working with nRF53 articles. The nRF5340 is a dual core chip and as such it is somewhat more complex for development.

Best regards,

Hieu

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

aorion — Tue, 25 Oct 2022 14:42:53 GMT

Hi Hieu,

Thank you for your patience.

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.

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

Hieu — Tue, 25 Oct 2022 10:31:58 GMT

Hi Alex,

[quote user="aorion"]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[/quote]

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?

[quote user="aorion"]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? [/quote]

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.

[quote user="aorion"]For example as I understand, I should not be able to use RTT on Thingy53 but it is working fine. [/quote]

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.

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

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:

[quote user="aorion"]I am not able to see status: "okay" in my zephyr.dts (and the binding fails).[/quote]

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

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

aorion — Mon, 24 Oct 2022 17:41:40 GMT

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

> 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

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

Hieu — Mon, 24 Oct 2022 10:09:22 GMT

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.

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

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

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

aorion — Mon, 24 Oct 2022 05:45:44 GMT

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.