Zephyr I2S nrfx_i2s.c Assertion Fail and "Cannot write in state: 4" Error During Matter Example Modification

Hi all,

I'm modifying the Matter Light Bulb example from Nordic's nRF Connect SDK to integrate I2S audio output on the nRF5340 DK. The goal is to play a continuous beep waveform through an external I2S DAC (UDA1334A).

I've implemented a Zephyr thread that handles I2S audio streaming using memory slabs. The configuration uses a 16 kHz sample rate, 16-bit stereo format, and I stream a looped sine waveform buffer.

The issue arises when I trigger I2S playback from within a Matter event callback (not from a button callback). Specifically, I’m using the CHIP Tool on pi device to commission and control the device over Matter. Once I trigger the playback (e.g., via an On/Off command), the following error occurs:

E: Cannot write in state: 4
I2S write failed: -5
ASSERTION FAIL @ nrfx_i2s.c:510
E: r0/a1:  0x00000004  r1/a2:  0x000001fe  r2/a3:  0x00000001
E: r3/a4:  0x00000004 r12/ip:  0x00000000 r14/lr:  0x00033315
E:  xpsr:  0x09000000
E: Faulting instruction address (r15/pc): 0x0007bce0
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x2000ff70 (main)
E: Halting system

This happens during a call to i2s_buf_write(). From what I understand, state 4 corresponds to NRFX_I2S_STATE_RUNNING, which should be valid for writes. But the assertion and kernel panic suggest otherwise.

Implementation details:
Zephyr version: [insert version]

nRF Connect SDK: 2.9.0

Board: nRF5340 DK

I2S settings: 16 kHz, 16-bit stereo, master mode

Threading: I2S audio playback is managed in a separate Zephyr thread

Triggering: I2S is triggered from the Matter event callback (not a button interrupt)

Commissioning: Done using CHIP Tool

I use i2s_buf_write() . I also use semaphores and thread signaling to start/stop playback cleanly.

Questions:
1. What are the valid I2S state transitions when writing with i2s_buf_write()?

2. Are there timing/threading concerns with calling I2S APIs from within a Matter callback context?

3. What can cause the nrfx I2S driver to assert in nrfx_i2s.c:510 while in NRFX_I2S_STATE_RUNNING?

4. Are there recommended best practices for triggering I2S audio playback in Zephyr from a Matter application?

5. Could the Matter stack or scheduler delay thread execution in a way that leads to I2S state issues?

Any insight into the correct way to safely stream I2S audio within a Matter-enabled Zephyr application (especially from event callbacks) would be greatly appreciated.

Related