X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Quintin H. — Mon, 21 Aug 2023 18:16:09 GMT

Thanks for your help Ladivin ! I'll try out the new sample you provided alongside you when I get the time to do so.

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Ladivin — Mon, 21 Aug 2023 11:55:42 GMT

Hi Quintin, thanks for testing this.

Long story short, the division by zero issue can be solved by changing hfclkaudio-frequency from 11289600 to 12288000. The thing is that find_suitable_clock() from zephyr\drivers\i2s\i2s_nrfx.c performs quite a few computations to determine the correct frequency settings - more on this here. Apparently, some of the computations are not robust enough and a wrong combination of inputs can cause Division by zero (we're considering creating a PR to propose a fix).

This will solve the Division by zero issue, but we're still not there. Our code is based on this sample (I assume that yours is too?). When I measured the output clock frequency and it's around 4 MHz. This exceeds maximal frequency the mic can handle. Also this is two times more than the documentation of this sample says the frequency should be. So clearly, there's still something wrong.

Currently, we shifted our focus to this sample because we believe it might be easier to make it working with the mic.

Ladivin

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Quintin H. — Sat, 19 Aug 2023 02:44:39 GMT

***** USAGE FAULT *****em
[00:00:00.272,125] <err> os:   Division by zero
[00:00:00.272,155] <err> os: r0/a1:  0x0010ad72  r1/a2:  0x00000000  r2/a3:  0x0056b800
[00:00:00.272,155] <err> os: r3/a4:  0x00000000 r12/ip:  0x0000ad72 r14/lr:  0x000061d7
[00:00:00.272,155] <err> os:  xpsr:  0x49000000
[00:00:00.272,186] <err> os: Faulting instruction address (r15/pc): 0x000061de
[00:00:00.272,216] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:00.272,247] <err> os: Current thread: 0x200009b0 (main)

Ladivin I tried out your solution, and it seems like whenever I remove I2S_FMT_BIT_CLK_INV it throws a Div by Zero error regardless of swapping the L/R config. It throws the same EINVAL error if I leave it as it was originally.

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Kenneth — Thu, 17 Aug 2023 14:39:12 GMT

Nice Ladivin , this sounds like something that should work yes. I don't have the possibility to try it myself, but looks very promising! thank you.

Kenneth

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Ladivin — Thu, 17 Aug 2023 14:34:20 GMT

Hello Kenneth and Quintin H.,

me and my colleague are currently struggling with the very same issue with the same combination of hardware.

I believe I have a workaround but - and I cannot stress this enough - I haven't had a chance to test it yet. Long story short, what I propose is to comment out I2S_FMT_BIT_CLK_INV in mpxxdtyy_i2s_configure(), to close solder bridge SB30 and to open SB28 on the shield.

Now, why I think it will help. If I2S_FMT_BIT_CLK_INV is not set, SD data gets sampled on rising edge of clk signal. If it is set, the data gets sample on falling edge of the clock -> and that's what the microphone on the shield expects. We cannot make nrf5340 to fulfil this expectation, but we can change what the mic expects.

Figure 2 in mic's datasheet is the key. It says that if the L/R input of the mic is connected to GND, data bit is send on falling edge of the clk. If L/R is connected to Vdd, rising edge is used instead. Datasheet of the shield reveals that L/R is connected to GND by default. But if you close SB30 and open SB28, L/R gets connect to Vdd. Thanks to that data bit should be send on rising edge of the clk and thus I2S_FMT_BIT_CLK_INV wouldn't be needed.

I will have a chance to test this with the actual HW later next week. You're more than welcome to try it too, but don't yell at me if it does not work 😄

Ladivin

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Kenneth — Thu, 17 Aug 2023 09:54:48 GMT

Interesting, I can see that in mpxxdtyy-i2s.c it configure inverted bit clock, ref in mpxxdtyy_i2s_configure():

i2s_cfg.format = I2S_FMT_DATA_FORMAT_LEFT_JUSTIFIED | I2S_FMT_BIT_CLK_INV;

This I2S_FMT_BIT_CLK_INV configuration is not supported by our I2S hardware, which I assume why it throws an error. But I don't understand why the bit clock needs to be inverted, isn't this just controlling left and right channel?

Kenneth

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Quintin H. — Wed, 16 Aug 2023 20:43:36 GMT

I debugged \zephyr\drivers\audio\mpxxdtyy-i2s.c and found that the EINVAL was triggered from the the value that came from the i2s_configure function as seen below:

ret = i2s_configure(config->comm_master, I2S_DIR_RX, &i2s_cfg);
	if (ret != 0) {
		LOG_ERR("I2S device configuration error");
		return ret;
	}

Looking into it deeper I edited my pr.conf file to set CONFIG_LOG=y and debugged zephyr\drivers\i2s\i2s_nrfx.c. I am getting two LOG_ERR messages.

[00:00:00.444,732] <err> i2s_nrfx: Unsupported stream format: 0x13
[00:00:00.444,732] <err> mpxxdtyy: I2S device configuration error
microphone configuration error -22

The i2s_nrfx error was generated from the snippet below:

if ((i2s_cfg->format & I2S_FMT_DATA_ORDER_LSB) ||
	    (i2s_cfg->format & I2S_FMT_BIT_CLK_INV) ||
	    (i2s_cfg->format & I2S_FMT_FRAME_CLK_INV)) {
		LOG_ERR("Unsupported stream format: 0x%02x", i2s_cfg->format);
		return -EINVAL;
	}

i2s_cfg->format = 19 '\023'

RE: X-NUCLEO-IK02A1 Microphone Example: dmic_configure returns -22

Kenneth — Wed, 16 Aug 2023 12:31:14 GMT

Dont' know, but do debugging \zephyr\drivers\audio\mpxxdtyy-i2s.c provide any more insight to what parameter(s) trigger EINVAL?

Kenneth