nRF5340 DK + MEMS mic: can't allocate buffers for dmic driver?

[oolaruu]

Hi there,

I've got an nRF5340 DK that is connected to a MEMS microphone. The pin assignments are correct and I've verified good clock and data signals (all 2ms of it) to the MEMS mic, all within the spec of the mic's datasheet.

When my application runs, I issue the trigger dmic_trigger(mic, DMIC_TRIGGER_START) and immediately try to pull data from the kernel's memory slab, however it's failing and giving the reason that the buffer is bad. Here's the example code snippet:

            dmic_trigger(mic, DMIC_TRIGGER_START);

            void* mem_block;
            size_t size;
            int read_rc = dmic_read(mic, 0, &mem_block, &size, 10);
            LOG_INF("dmic_read: %d, bytes: %zu\n", read_rc, size);

            dmic_trigger(mic, DMIC_TRIGGER_STOP);

[00:00:00.424,957] <inf> dmic_nrfx_pdm: PDM clock frequency: 1032258, actual PCM rate: 16129
[00:00:01.486,114] <err> dmic_nrfx_pdm: No room in RX queue (-35) 0x20008548, 0x20008558
[00:00:01.494,873] <err> dmic_nrfx_pdm: Failed to set buffer: 0x0bad000b (sz: 0)
[00:00:01.502,929] <inf> mic_thread: dmic_read: 0, bytes: 0

The memory slab is initialized as so:

K_MEM_SLAB_DEFINE(mem_slab, 328, 256, 4);

What could be going on with this? is it an allocation issue?

[Vidar Berg]

Hello,

I wasn't able to reproduce this issue with the dmic sample in /zephyr/samples/drivers/audio/dmic. However, the 'No room in RX queue' error indicates that you've run out of space in your message queue, and the subsequent error seems to be a consequence of the first.

Please try to increase the queue size in your devicetree overlay and see if it helps.

queue-size property for nrf-pdm binding :

Example of what the overlay may look like with the queue-size property:

Best regards,

Vidar

[oolaruu]

Interesting, thanks for the pointer. I've increased this to 8,16,32 without any real success. The app crashes when using 16 or 32 funny enough. One thing to note, I have a separate thread that is doing the `dmic_trigger` and `dmic_read` , I wouldnt think that makes any difference but I'm second guessing everything at this point.

Here's my overlay

&pinctrl {
	pdm0_default_alt: pdm0_default_alt {
		group1 {
			psels = <NRF_PSEL(PDM_CLK, 1, 12)>,
				    <NRF_PSEL(PDM_DIN, 1, 13)>;
		};
	};
};

dmic_dev: &pdm0 {
	status = "okay";
	pinctrl-0 = <&pdm0_default_alt>;
	pinctrl-names = "default";
	clock-source = "PCLK32M_HFXO";
	queue-size = <8>;
};

and here's the config I'm using:

	struct pcm_stream_cfg stream = {0};
    stream.pcm_rate = AUDIO_SAMPLE_RATE_HZ; // 16384
    stream.pcm_width = 16; // bits
    stream.mem_slab = &mem_slab;


	struct dmic_cfg cfg = {0};
    cfg.io.min_pdm_clk_freq = 400000;
    cfg.io.max_pdm_clk_freq = 3300000;
    cfg.io.min_pdm_clk_dc = 40;
    cfg.io.max_pdm_clk_dc = 60;

    // PDM clock frequency: 561403,actual PCM rate: 7017

    cfg.streams = &stream;
    cfg.streams->block_size = MEM_BLOCK_SIZE;

    cfg.channel.req_chan_map_lo = dmic_build_channel_map(0, 0, PDM_CHAN_LEFT);
    cfg.channel.req_num_chan = 1;
    cfg.channel.req_num_streams = 1;

    int32_t rc = dmic_configure(mic, &cfg);

[Vidar Berg]

Maybe the PDM is collecting too many samples between `dmic_trigger` and `dmic_read` since you are doing the read from another thread. To confirm this, maybe you can increase the log level in the dmic driver.

This line, for instance, will show how many times the buffer was queued before the 'No room in RX queue' error occurs and it fails.

https://github.com/nrfconnect/sdk-zephyr/blob/1bf7c391b89be76893defcc48dcfa5ea020ac720/drivers/audio/dmic_nrfx_pdm.c#LL87C12-L87C12 

[oolaruu]

it's very strange, I now only ran this in the main thread and it just reboots the soc:

*** Booting Zephyr OS build v3.2.99-ncs2 ***
[00:00:00.276,824] <inf> dmic_nrfx_pdm: PDM clock frequency: 1032258, actual PCM rate: 16129
[00:00:19.438,201] <inf> dmic_nrfx_pdm: Queued buffer 0x200092b8
�*** Booting Zephyr OS build v3.2.99-ncs2 ***d buffer 0x200092b8

[Vidar Berg]

It appears that the device is being reset before it can print the error log from the error handler. To make it easier to trace back where the error occured, you may want to build your app with CONFIG_RESET_ON_FATAL_ERROR=n.