RT6XX I2S test fails after d92d1f162af3ba24963f1026fc0a304f1a44d1f3

[mmahadevan108]

Describe the bug
The I2S test tests/drivers/i2s/i2s_speed starts to fail after commit: d92d1f1

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=board\mimxrt685_evk_cm33
3. make
4. See error

Expected behavior
The test should pass

Logs and console output
Below failure is seen on the console output:

E: ***** BUS FAULT *****
E:   Precise data bus error
E:   BFAR Address: 0xc5970e48
E: r0/a1:  0x301822c4  r1/a2:  0x00000000  r2/a3:  0xc5970e48
E: r3/a4:  0x00000001 r12/ip:  0x00000000 r14/lr:  0x18006e55
E:  xpsr:  0x41000000
E: Faulting instruction address (r15/pc): 0x18009b62
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x30180e10 (test_i2s_transfer_short)
E: Halting system

Environment (please complete the following information):

• OS: Linux
• Toolchain: e.g Zephyr SDK
• Commit SHA: 8b13046

[mmahadevan108]

cc @hakehuang @MaureenHelm @dleach02

[MaureenHelm]

Is the driver assuming initialized memory allocation?

[mmahadevan108]

@dcpleung any suggestions for this issue we are seeing the I2S tests

[dcpleung]

That's weird... as far as I can tell, the test does not use k_heap.

As for the assert, did it return -EIO or -EAGAIN? Given the debug message above saying need retry, I am assuming -EAGAIN. If this is the case, maybe the timeout in the driver is not long enough? Could you try to loop the call to i2s_mcux_read() just above the assertion a few times to see if it goes through? I don't have anything hardware on hand to test I2S so I can't debug this locally.

[mmahadevan108]

The test uses k_mem_slab. Would this change have an impact?

[dcpleung]

K_MEM_SLAB_DEFINE() is not backed by k_heap. There doesn't seem to be any connection to the failure.

My guess is that this may be due to memory alignment. The k_heap change moves other symbols around in memory. That commit might cause issue if the hardware requires certain memory alignment of the buffers. If this is indeed the case, we have been lucky so far on the test, as adding one uint32_t might have broken the test.

[mmahadevan108]

Thank you, I was able to find a fix.

[mmahadevan108]

Issue has been fixed