Hi @Kan_Li ,
The code does not attempt to read or write the EPSR, and the application runs in XIP mode. I don't have access to EVK but I have a previous board revision which uses another SDRAM chip, and the application runs with no problems. This points to SDRAM misconfiguration or hardware problems.
The exceptions are different most of the time and they occur in different places. Here's an example:
[00:26:09.898,000] <err> os: ***** MPU FAULT *****
[00:26:09.906,000] <err> os: Instruction Access Violation
[00:26:09.914,000] <err> os: r0/a1: 0x00000001 r1/a2: 0x80101c60 r2/a3: 0x80101c60
[00:26:09.925,000] <err> os: r3/a4: 0x80101c60 r12/ip: 0x8012b4bc r14/lr: 0x300335ad
[00:26:09.936,000] <err> os: xpsr: 0x20000246
[00:26:09.943,000] <err> os: s[ 0]: 0x80101c60 s[ 1]: 0x800026c4 s[ 2]: 0x00000000 s[ 3]: 0x3005c74c
[00:26:09.955,000] <err> os: s[ 4]: 0x3005c730 s[ 5]: 0x30031fef s[ 6]: 0x80082460 s[ 7]: 0x00072300
[00:26:09.968,000] <err> os: s[ 8]: 0x00000038 s[ 9]: 0x3000debb s[10]: 0x8012b4c8 s[11]: 0x3000a52f
[00:26:09.981,000] <err> os: s[12]: 0x00000000 s[13]: 0xfffffffd s[14]: 0xaaaaaaab s[15]: 0xaaaaaaab
[00:26:09.993,000] <err> os: fpscr: 0xaabaaaaa
[00:26:10.000,000] <err> os: Faulting instruction address (r15/pc): 0x80101c60
[00:26:10.010,000] <err> os: >>> ZEPHYR FATAL ERROR 20: Unknown error on CPU 0
[00:26:10.020,000] <err> os: Fault during interrupt handling
[00:26:10.029,000] <err> os: Current thread: 0x80101c60 (lvgl_handler_tid)
[00:26:10.039,000] <err> os: Halting system
The PC points to SDRAM, which is odd because the application is not supposed to execute any functions from SDRAM. Some of the registers contain a suspicious value of 0xaaaaaaab, which may mean stack poisoning as Zephyr fills stacks with 0xaaaaaaaa pattern.
When I vary the SDRAM timing parameters in my DCD file, the errors tend to increase in frequency - again, that makes me think the SDRAM is the issue, however I can't pinpoint the exact reason.
I've tried lowering the SDRAM speed but crashes still appear. Another thing I've noticed is that AXIBUSERR in SEMC_INTR is set - that's not happening when running the bare metal application.