I2S Voltage levels for Verdin iMX8MP

We are developing an I2S1 interface for an AK4619 CODEC on a Verdin Development board with a Verdin IMX8MP SOM. The SYNC voltage level out of the SOM looks good (1.8V), however the BCLK, MCLK, and DOUT0 signals are very low, approximately 200mV. BCLK and MCLK do look like good clock signals however.

System Details as follows:

  • Verdin V1.1E Dev board
  • IMX8MP SOM 0058
  • Using I2S_1 Port with the following connections
  • X2-11 (SODIMM_30) for I2S1_BCLK
  • X2-12 (SODIMM_32) for I2S1_SYNC
  • X2-15 (SODIMM_38) for I2S1_MCLK
  • X2-13 (SODIMM_34) for I2S1_DOUT0
  • X2-14 (SODIMM_36) for I2S1_DIN0.

I disconnected the CODEC (so only looking at the Toradex signals) and the signals did not change. Also, to confirm, the jumpers between X2 and X4 for these signals have been removed.

Is there some software or hardware setting/change required to change these voltage levels?

I am primarily a hardware engineer so if there are device tree or software setup questions or changes, I will need to figure out how to loop in my software engineer on this ticket.

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Thank you for reaching out with your question. It seems you’re encountering low voltage levels on the BCLK, MCLK, and DOUT0 signals of the I2S1 interface on your Verdin iMX8MP SOM. Since you’ve already checked the hardware connections, let’s focus on potential software configurations that might help.

  1. Voltage Level Configuration: Ensure that the I/O voltage domain for the I2S signals is set to 1.8V, as this is the expected level for the SYNC signal. This configuration is typically managed through the device tree.

  2. Device Tree Adjustments: The device tree might need to be reviewed to ensure the correct voltage levels are set for the I2S interface. Check the device tree files for any settings related to the I2S1 interface, ensuring they are configured to use the correct voltage levels. This may involve setting the appropriate pin control settings and confirming that the I2S1 interface is properly enabled.

  3. Software Initialization: Verify that the software is correctly initializing the I2S interface. This includes checking any initialization scripts or configurations that might affect the I2S signal levels. If you are using Torizon, ensure that the correct device tree overlays are applied and that the I2S interface is enabled in the software stack.

Since you mentioned you might need to involve a software engineer, it would be beneficial to collaborate with them to review these configurations.

I hope this helps you resolve the issue. If you have any further questions, feel free to ask.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Imx7 MAX98357A Device Tree Settings.

What is your pinmux settings for that pins?

My software engineer tried to e-mail the following reply (because the e-mail said we could simply reply), but I am guessing because it didn’t come from me, it just fell into the void?

Email follows:

Alex,

Here is the pinmux info. It is also of note that we had to turn around the MCLK & BCLK because the AK4619 will not derive them, they have to be sourced from the CPU.

We build our own kernel and device tree. The kernel is based on toradex_5.15-2.2.x-imx.

Our main device tree file is:
arch\arm64\boot\dts\freescale\imx8mp-verdin-dev-icvr.dts

It includes, in this order:
#include “imx8mp-verdin.dtsi”
#include “imx8mp-verdin-nonwifi.dtsi”
#include “imx8mp-verdin-dev.dtsi”

Those include files are unmodified from the toradex_5.15-2.2.x-imx version from Torizon.

Our DTS file includes the following pinmux settings:
&pinctrl_sai1 {
fsl,pins =
<MX8MP_IOMUXC_SAI1_MCLK__AUDIOMIX_SAI1_MCLK 0x96>, /* SODIMM 38 /
<MX8MP_IOMUXC_SAI1_RXD0__AUDIOMIX_SAI1_RX_DATA00 0x1d6>, /
SODIMM 36 /
<MX8MP_IOMUXC_SAI5_MCLK__AUDIOMIX_SAI1_TX_BCLK 0x1d6>, /
SODIMM 30 /
<MX8MP_IOMUXC_SAI5_RXD1__AUDIOMIX_SAI1_TX_SYNC 0x1d6>, /
SODIMM 32 /
<MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI1_TX_DATA00 0x96>; /
SODIMM 34 */
};

Here is the snippet with our AK4619 codec, including the clock source change,

sound_ak4619: sound-ak4619-1 {
        compatible = "simple-audio-card";
        simple-audio-card,bitclock-master = <&dailink_cpu>;
        simple-audio-card,format = "i2s";
        simple-audio-card,frame-master = <&dailink_cpu>;
        simple-audio-card,mclk-fs = <256>;
        simple-audio-card,name = "icvr-ak4619-0";
        simple-audio-card,routing =
                "Line Out", "AOUT1L",
                "Line Out", "AOUT1R",
                "Line Out", "AOUT2L",
                "Line Out", "AOUT2R",
                "AIN1L", "Line In",
                "AIN1R", "Line In",
                "AIN2L", "Line In",
                "AIN2R", "Line In";
        simple-audio-card,widgets =
            "Line Out", "Line Out",
            "Line", "Line In";

        status = "okay";

        dailink_master_cs0: simple-audio-card,codec {
                sound-dai = <&spi1_1>;
                clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIO_BLK_CTRL_SAI1_MCLK1>;
        };

        dailink_cpu: simple-audio-card,cpu {
                sound-dai = <&sai1>;
        };
};

We disabled status of the sound_ad1938 driver but left it present in the file.

Thanks,
David

Your pad settings look OK. I’ve checked MCLK (SODIMM 38) and TX_BCLK (0x1d6, SODIMM 30) using the prebuilt Verdin-iMX8MP Reference Multimedia Image (TDX Wayland with XWayland 5.7.6+build.29, Dunfell) with imx8mp-verdin-wifi-dev.dtb and the signal levels appear correct - 1.8V.

I forwarded your response to my software engineer and (if I understand him correctly), the prebuilt image uses the on-board CODEC as the source for those clocks, not the Toradex SOM.

His question to pass to you is, “In order to use the AK4619, we need to have the CPU be the source clock for MCLK and BCLK. What changes do we need to make to pinmux and other DTS settings to configure that?”

Thanks!

On the Verdin Dev Board, the MCLK (SODIMM 38) signal is directly connected to the NAU88C22YG codec’s pin 11 (MCLK). Since this pin is input-only, it cannot function as a clock source.

You can also check that sound card configuration uses

codec_dai: simple-audio-card,codec { clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIO_BLK_CTRL_SAI1_MCLK1>;

https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm64/boot/dts/freescale/imx8mp-verdin-dev.dtsi?h=toradex_5.15-2.2.x-imx#n19

Alexander Samutin
Toradex

Interesting. I had not looked closely at the NAU88C22YG signal direction. (As we stated previously, we had disconnected the NAU88C22YG by removing the X3 jumpers.)

I have passed this additional code example to our software engineer.

As a side question, does it seem reasonable that those signal levels could be only 0.2V peak based on possible pin settings? I am guessing so, but that caught me by surprise.

Thanks!
Ben

>>does it seem reasonable that those signal levels could be only 0.2V peak based on possible pin settings?
Theoretically, it is possible if the pin is set as open-drain and somehow gets pulled up to 0.2V (through leakage or backfeeding).

But your pad settings looks exactly as ours:

	pinctrl_sai1: sai1grp {
		fsl,pins =
			<MX8MP_IOMUXC_SAI1_MCLK__AUDIOMIX_SAI1_MCLK		0x96>,	/* SODIMM38 */
			<MX8MP_IOMUXC_SAI1_RXD0__AUDIOMIX_SAI1_RX_DATA00	0x1d6>,	/* SODIMM36 */
			<MX8MP_IOMUXC_SAI5_MCLK__AUDIOMIX_SAI1_TX_BCLK		0x1d6>,	/*SODIMM 30 */
			<MX8MP_IOMUXC_SAI5_RXD1__AUDIOMIX_SAI1_TX_SYNC		0x1d6>,	/*SODIMM 32 */
			<MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI1_TX_DATA00	0x96>;	/* SODIMM34 */

How exactly did you perform the level measurements?

Alexander Samutin
Toradex

We added pins into those signals on X3 and measured on an oscilloscope with 1M scope probes.

And, the behavior happens when our CODEC board is disconnected. In other words, it happens with the Verdin alone…which I think would be extremely unlikely since there doesn’t appear to be anything else connected to those signals on the evaluation board.

Although…I just thought of one thing (I am at home right now, not with the hardware in the office), I could check the 1x vs 10x probe and probe settings…That could totally explain it. I am not scheduled to be in the office until Tuesday, but this is something I need to check. Maybe I can see if someone will be in the office tomorrow. I really don’t want to drive in for such a minor thing, but we also can’t really afford to wait until Tuesday to progress on this. I will update you when I am able to check this.

Admittedly we started probing since our CODEC wasn’t working…but there could be a different problem in terms of CODEC communication if these levels are fine.

This morning we confirmed that the signal level issue was a scope probe issue. The Scope was not recognizing some of our 10X probes. With manual over-ride of the probe settings, the signals look correct at 1.8V.

We are still not able to confirm our CODEC is operating properly, but at least for the moment, this appears to be a CODEC problem, not a Toradex SOM problem.

Thanks for the help. I believe this issue can be closed.