Audio via I2S from external SoC into iMX8MP module - Capturing fails

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Audio via I2S from external SoC into iMX8MP module - Capturing fails

Jump to solution
2,474 Views
freshmango90
Contributor III

I am using imx-audio-card which uses sai1 snd-soc-dummy-dai-0

I have an external SoC connected to iMX8MP module via I2S, there's no exposed codec for me to use, hence why I'm using a dummy codec.

I can view them in aplay -L which will show:

hw:CARD=imxaudiocard,DEV=0
    imx-audio-card, sai1 snd-soc-dummy-dai-0
    Direct hardware device without any conversions
plughw:CARD=imxaudiocard,DEV=0
    imx-audio-card, sai1 snd-soc-dummy-dai-0
    Hardware device with all software conversions
default:CARD=imxaudiocard
    imx-audio-card, sai1 snd-soc-dummy-dai-0
    Default Audio Device
sysdefault:CARD=imxaudiocard
    imx-audio-card, sai1 snd-soc-dummy-dai-0
    Default Audio Device
dmix:CARD=imxaudiocard,DEV=0
    imx-audio-card, sai1 snd-soc-dummy-dai-0
    Direct sample mixing device

I can play audio via this and it works.

aplay -D default:CARD=imxaudiocard music.wav

Similar results in the code snippet above using arecord -L. I'm able to record using: 

arecord -D default:CARD=imxaudiocard -r 32000 -c 2 -d 20 -f S24_3LE test.wav

 

However, the test.wav comes out blank; I cannot seem to record sounds. FYI - there's no amixer controls, so I can't seem to set to CAPTURE.

Any idea how I can accept the audio in via I2S when I can already playback the audio out via I2S?

 

0 Kudos
Reply
1 Solution
2,148 Views
freshmango90
Contributor III

SOLVED! 

On the development board, the module was physically connected to the codec. We needed to break the lines to stop the voltage leakage. 

So disabling the codec in the device tree wasn’t sufficient, hardware work was needed to be done.

Thank you @Manuel_Salas and @jamesbone - I definitely learned a lot in this journey that I would not have learned otherwise. Thanks again!

View solution in original post

0 Kudos
Reply
14 Replies
2,428 Views
jamesbone
NXP TechSupport
NXP TechSupport

You can test with an oscilloscope, the clock signal when it is in the record mode, if the clock it is not setup then in the Device tree you can change it.

the pcm_write it is function in the alsa driver,  you can get the Kernel Log using Dmesg command, let me share a link on how to

https://www.linuxfoundation.org/blog/blog/classic-sysadmin-viewing-linux-logs-from-the-command-line

0 Kudos
Reply
2,358 Views
freshmango90
Contributor III

Hello James, 

The dmesg command is not available and it is not in /var/log either. 

I did some more testing, so here's the scenario,

  • I have the oscilloscope connected to SAI1_TX_BCLK
  • music from external SoC is always streaming.
  • if I have external SoC as master, this line is busy only when I run the arecord command on the imx8mp, otherwise idle. 
  • if I have external SoC as slave, when I run arecord on imx8mp, I see a clean clock cycle
    • if i change the oscilloscope to pin SAI1_RX_DATA00, I see activity, but too small to hit any threshold to make it "bit 1".

Any ideas?

0 Kudos
Reply
2,344 Views
freshmango90
Contributor III

Hello @jamesbone 

Our setup is as such:

External SoC --> Level shifter (3.3V to 1.8V) --> imx8mp

We have the oscilloscope probed at the RX line of the imx8mp (SAI1_RX_DATA00). This is what we see: 

freshmango90_0-1744145994407.jpeg

 

The highest voltage never reaches 1.8V, and the high seems to be at 0.85V, which is too low and never gets registered as high in the imx8mp RX line.

 

If we unplug the RX line from the imx8mp while everything is intact, the oscilloscope jumps up above 1.8V, as shown: 

freshmango90_1-1744146100040.jpeg

The oscilloscope is reading what is coming from the SoC via level shifter.

 

My question is, why is connecting the imx8mp RX line pulling the voltage down such that the high doesn't trigger as 1 in the input, thus producing complete silence in the eyes of imx8mp?

 

Tags (1)
0 Kudos
Reply
2,308 Views
Manuel_Salas
NXP TechSupport
NXP TechSupport

Hello @freshmango90 

 

It seems that you have enabled pull-down on the RX pin on i.MX8MP.

Could you please share your device tree related to the the SAI configuration? If possible, share the schematic and part number of the level shifter.

Best regards,

Salas.

0 Kudos
Reply
2,302 Views
freshmango90
Contributor III
partial device tree:
&{/} {
    sound_i2s_card {
        status = "okay";
        compatible = "fsl,imx-audio-card";
        model = "imx-audio-card";
        pri-dai-link {
            link-name = "sai1";
            format = "i2s";
            cpu {
                sound-dai = <&sai1>;
            };
        };
    };
};


&sai1 {
    status = "okay";
    pinctrl-0 = <&pinctrl_sai1_bclk_lrclk_dout_din>;
    pinctrl-names = "default";
};

&iomuxc {
    pinctrl_sai1_bclk_lrclk_dout_din: my_sai_grp {
        fsl,pins =
        <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 */
        <MX8MP_IOMUXC_SAI1_RXD0__AUDIOMIX_SAI1_RX_DATA00 0x1d0>; /* SODIMM 36 */
    };
};

 

I have RX line to be 1d0 because I wanted to reduce the output drive strength to keep it as an input.

 

Here is the level shifter datasheet. This device does use pull-up resistors.

https://www.ti.com/lit/ds/symlink/txs0102.pdf?HQS=dis-dk-null-digikeymode-dsf-pf-null-wwe&ts=1744212...

Our schematic is the same as the one shown in 9.2 Typical application with the only difference with OE being connected to 1.8V to always enable the level shifter.

 

Tags (1)
0 Kudos
Reply
2,296 Views
Manuel_Salas
NXP TechSupport
NXP TechSupport

Hello  @freshmango90 

 

I can confirm that the TXS0102 has internal pull-ups resistors of 10K, so, you can disable the pull ups from i.MX8MP.

Also, the TXS0102 is Open drain, so, you must disable Open Drain from i.MX8MP.

Please try it.

 

Best regards,

Salas.

0 Kudos
Reply
2,237 Views
freshmango90
Contributor III

Hello @Manuel_Salas ,

I appreciate your insight, and we've went ahead and checked with the manual on the register (section 8.2.4.232 in the IMX8MPRM, or here's the snippet)

freshmango90_0-1744296467921.png

 

So this would mean that Bit 5 (open drain field) should be 0 and Bit 6 (pull up/down config field) should be 1. That means 0x1d6. It is what I currently have. 

 

I've also played around with the settings, and tried with 0x0d6, 0x0d0, 0x096 and these do not solve the issue. The signal is still too low. 

I'm at a loss, not sure what to do.

0 Kudos
Reply
2,235 Views
freshmango90
Contributor III
Sorry, I've set the Bit 8 (pull select) as disabled, which is 0x0d6, which I've already tried.
0 Kudos
Reply
2,217 Views
freshmango90
Contributor III

Some further testing:

Pin 36 issue?

I wanted to know if there's any issue with the pin 36, so we've made that as a TX line as such:

<MX8MP_IOMUXC_SAI1_RXD0__AUDIOMIX_SAI1_TX_DATA01 0x1d6>; /* SODIMM 36 */

And it is behaving the same with as if it's the RX line (pulls lower when connected)

So maybe something is wrong with the imx8mp module, and I have an extra one, so I replace the module. Same issue. So...

RXD1 data line

So we thought maybe the pin 36 has some hardware issue or corruption, so I wanted to use another RX line, which is in pin 220 using this line:

<MX8MP_IOMUXC_SAI1_RXD1__AUDIOMIX_SAI1_RX_DATA01 0x1d6>; /* SODIMM 220 */

Suddenly, the audio card is not available, so I cannot send/receive signals to test if it pulls high/low. aplay -L does not show this, nor is it in /proc/asound/cards. I've also tried disabling one pinctrl as it uses pin 220 as such: 

&pinctrl_gpio7{
    status = "disabled";
};

Questions:

  1. Do you have any idea why pin 36 always pulls lower, regardless of pin pad configuration or what it's pixmux'ed to?
  2. Why changing the RX line from pin 36 to pin 220 not recognize the imx-audio-card (sound card)?
0 Kudos
Reply
2,149 Views
freshmango90
Contributor III

SOLVED! 

On the development board, the module was physically connected to the codec. We needed to break the lines to stop the voltage leakage. 

So disabling the codec in the device tree wasn’t sufficient, hardware work was needed to be done.

Thank you @Manuel_Salas and @jamesbone - I definitely learned a lot in this journey that I would not have learned otherwise. Thanks again!

0 Kudos
Reply
2,442 Views
jamesbone
NXP TechSupport
NXP TechSupport

Since you are using a Dummy Codec, the issue would be the setup of MAster / Slave  mode.

pcm_write return EIO error, that means I/O is not setup. And master mode can wok but slave mode not.

Can they check if bit clock is generated with your Dummy and slave mode? Check if any message from kernel log.

0 Kudos
Reply
2,432 Views
freshmango90
Contributor III
Hello James,

Thanks for your reply. I currently have it set up such that the module with imx8mp is a slave, and the external SOC is a master. I did not modify this as I'd assume the I2S is bidirectional (I have both data in and data out connected).

How would I check the pcm_write error? or the bit clock is generated?

Lastly, how do I check any message from Kernel Log?
0 Kudos
Reply
2,469 Views
Manuel_Salas
NXP TechSupport
NXP TechSupport

Hello @freshmango90 

I hope you are doing very well.

 

Could you please share what codec are you using? BSP version also.

If possible, your device tree related to the codec.

Sometimes it happens when there is a connection between an i.MX and device like "MAX98357A" that is not a "codec", those are Digital amplifiers and eventually there are issues.

 

Best regards,

Salas.

0 Kudos
Reply
2,465 Views
freshmango90
Contributor III

 

Could you please share what codec are you using? BSP version also.

No codec - hence the dummy one. I just have the audio streaming coming directly from I2S with no I2C line.

BSP - not sure how to get this... I did uname -r though, and got: 5.15.148-6.8.1+git.1cbf48124747

If possible, your device tree related to the codec.

As for the device tree - I don't have that on hand, but it would create a new node to use fsl,imx-audio-card 

Sometimes it happens when there is a connection between an i.MX and device like "MAX98357A" that is not a "codec", those are Digital amplifiers and eventually there are issues.

As for your comment about digital amplifiers, could you elaborate on that? 

 

Tags (3)
0 Kudos
Reply