zephyr: I2S transfers causes exception/crash in xtensa/Intel S1000

Describe the bug When a memory slab is defined using the K_MEM_SLAB_DEFINE macro, exceptions/crashes are seen on an Intel S1000 board

To Reproduce Steps to reproduce the behavior:

merge the changes in PR #13222
make the following changes in tests/boards/intel_s1000_crb/src/i2s_test.c
- comment out the i2s_mem_slab and audio_buffers definitions
- replace them with K_MEM_SLAB_DEFINE(i2s_mem_slab, BLOCK_SIZE_BYTES, NUM_I2S_BUFFERS, 4);
- To see the exceptions (instead of a silent crash). change the thread start delay at by changing the thread definition at the end of the file as PRIORITY, 0, K_MSEC(100));
Disable logger by setting CONFIG_LOG=n in tests/boards/intel_s1000_crb/prj.conf
build and run the test on an Intel S1000 CRB

Expected behavior LEDs blink, DMA transfers successful, I2S transfers successful.

Screenshots or console output

*** Unhandled exception ****
Exception cause 12 (instr PIF data error):
  EPC1     : 0xbe00334f EXCSAVE1 : 0xbe004d6a EXCVADDR : 0x00000000
Program state (PS):
  INTLEVEL : 05 EXCM    : 0 UM  : 1 RING : 0 WOE : 1
  OWB      : 03 CALLINC : 2
Current thread ID = 0xbe00fd98
Faulting instruction address = 0xdeaddead
Fatal fault in ISR! Spinning...

Environment (please complete the following information):

Development OS: Linux
Toolchain: xt-xcc
Commit SHA used: 268572f5f04f5387ce408c6b4c992080848c6a2e

Additional context If an explicit k_mem_slab object is defined and initialized using k_mem_slab_init, there is no exception/crash.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 31 (25 by maintainers)

Commits related to this issue

soc: intel_s1000: change cached regions to write-through The i2s_cavs.c driver manipulates cache lines before commencing any DMA transfers. With write-back cache, if the DMA receive buffer is not ali... — committed to dcpleung/zephyr by dcpleung 5 years ago
soc: intel_s1000: change cached regions to write-through The i2s_cavs.c driver manipulates cache lines before commencing any DMA transfers. With write-back cache, if the DMA receive buffer is not ali... — committed to zephyrproject-rtos/zephyr by dcpleung 5 years ago

Most upvoted comments

I happened to introduce a couple of printk statements

@rgundi printk should not be used once the interface has started because it can delay the reloading of DMA resulting in transfer errors.

@rgundi @dcpleung based on some of your observations, my hypothesis would be that the crashes/exceptions are a result of unintended eviction of data from the cache. Since the entire internal memory is is configured with writeback data cache attribute, some data structures that are used by the program may share the same cache line as the mem_slab buffers. When data cache is invalidated, the data structure contents that have not been written back to memory will be evicted and replaced by the contents of memory causing non-deterministic behavior. Can you test by mapping the DACACHE_INVALIDATE macro to xthal_dcache_region_writeback_inv instead of xthal_dcache_region_invalidate?

sathishkuttan on Apr 6, 2019