Skip to content

Conversation

@ndreys
Copy link

@ndreys ndreys commented Nov 15, 2025

It seems to be possible for a race between data_handler() and the latter part of i2s_nrfx_write() to cause supply_next_buffers() to be called after nrfx_i2s_uninit() has run, causing

ASSERTION FAIL [p_cb->state == NRFX_DRV_STATE_POWERED_ON] @ WEST_TOPDIR/build/external-code/modules/hal/nordic/nrfx/drivers/src/nrfx_i2s.c:445
[00:00:25.492,095] <err> os: r0/a1:  0x00000004  r1/a2:  0x000001bd  r2/a3:  0x00000003
[00:00:25.492,095] <err> os: r3/a4:  0x00000004 r12/ip:  0x00000014 r14/lr:  0x000418a1
[00:00:25.492,126] <err> os:  xpsr:  0x01000000
[00:00:25.492,126] <err> os: s[ 0]:  0x20002460  s[ 1]:  0x00026c87  s[ 2]:  0x00000000  s[ 3]:  0x2000ec28
[00:00:25.492,126] <err> os: s[ 4]:  0x20002480  s[ 5]:  0x000531d3  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:25.492,156] <err> os: s[ 8]:  0x0005f854  s[ 9]:  0x2000249c  s[10]:  0x20002488  s[11]:  0x000524a5
[00:00:25.492,187] <err> os: s[12]:  0x36388f32  s[13]:  0x2000249c  s[14]:  0x200024a8  s[15]:  0x00041897
[00:00:25.492,187] <err> os: fpscr:  0x0005f854
[00:00:25.492,187] <err> os: Faulting instruction address (r15/pc): 0x0005248c
[00:00:25.492,248] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:25.492,279] <err> os: Current thread: 0x20001f88 (unknown)
[00:00:25.962,005] <err> os: Halting system

assert to happen. A burte force solution for this is to lock irqs to prevent this race from happening.

It seems to be possible for a race between data_handler() and the
latter part of i2s_nrfx_write() to cause supply_next_buffers() to be
called after nrfx_i2s_uninit() has run, causing

ASSERTION FAIL [p_cb->state == NRFX_DRV_STATE_POWERED_ON] @ WEST_TOPDIR/build/external-code/modules/hal/nordic/nrfx/drivers/src/nrfx_i2s.c:445
[00:00:25.492,095] <err> os: r0/a1:  0x00000004  r1/a2:  0x000001bd  r2/a3:  0x00000003
[00:00:25.492,095] <err> os: r3/a4:  0x00000004 r12/ip:  0x00000014 r14/lr:  0x000418a1
[00:00:25.492,126] <err> os:  xpsr:  0x01000000
[00:00:25.492,126] <err> os: s[ 0]:  0x20002460  s[ 1]:  0x00026c87  s[ 2]:  0x00000000  s[ 3]:  0x2000ec28
[00:00:25.492,126] <err> os: s[ 4]:  0x20002480  s[ 5]:  0x000531d3  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:25.492,156] <err> os: s[ 8]:  0x0005f854  s[ 9]:  0x2000249c  s[10]:  0x20002488  s[11]:  0x000524a5
[00:00:25.492,187] <err> os: s[12]:  0x36388f32  s[13]:  0x2000249c  s[14]:  0x200024a8  s[15]:  0x00041897
[00:00:25.492,187] <err> os: fpscr:  0x0005f854
[00:00:25.492,187] <err> os: Faulting instruction address (r15/pc): 0x0005248c
[00:00:25.492,248] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:25.492,279] <err> os: Current thread: 0x20001f88 (unknown)
[00:00:25.962,005] <err> os: Halting system

assert to happen. A burte force solution for this is to lock irqs to
prevent this race from happening.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants