v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

[NautDesigner]

Code runs fine in v2.53 but when running in v2.6, we get a kernel panic at the exit of a delayable workqueue function. 

Tracing the code and line number, it dies in Zephyr. No idea where to go from here so any help would be appreciated.

ASSERTION FAIL @ WEST_TOPDIR/zephyr/include/zephyr/drivers/gpio.h:883
[00:00:17.195,861] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000373 r2/a3: 0x00000000
[00:00:17.196,380] <err> os: r3/a4: 0x20010060 r12/ip: 0x000002ee r14/lr: 0x00045d0b
[00:00:17.196,899] <err> os: xpsr: 0x41000000
[00:00:17.197,265] <err> os: Faulting instruction address (r15/pc): 0x000668c2
[00:00:17.197,723] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:17.198,211] <err> os: Current thread: 0x2000fb38 (sysworkq)
[00:00:17.203,582] <err> os: Halting system

CONFIG_HW_STACK_PROTECTION=y
CONFIG_DYNAMIC_OBJECTS=y
CONFIG_HEAP_MEM_POOL_SIZE=98304
#131072
CONFIG_NRF_MODEM_LIB_HEAP_SIZE=4096
CONFIG_MAIN_STACK_SIZE=8192
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
#CONFIG_IDLE_STACK_SIZE=2048
CONFIG_AT_MONITOR_HEAP_SIZE=1024

[JyriLehtinen]

Our application is using the ST's LIS2DH on SPI bus with the Zephyr drivers, and it works fine on SDK version 2.5.1, but with 2.6.1 it causes the same assert error.

Still looking in to it, might have more information later.

[JyriLehtinen]

Alright, the issue was not present in the LIS2DH sample, but is in our production application, and for some reason the sensor driver doesn't handle the interrupts correctly, resulting in the assertion failure:

ASSERTION FAIL [(flags & ((1U << 21) | (1U << 22))) != 0U] @ WEST_TOPDIR/zephyr/include/zephyr/drivers/gpio.h:883
   Must either enable or disable interrupts

The 2.6.1 LIS2DH devicetree binding has new properties, int1-gpio-config and int2-gpio-config, setting them to <3> (LIS2DH_DT_GPIO_INT_LEVEL_HIGH) fixes the issue. A value of <0> results in the assert failure, I assume it's the default value.

EDIT: I noticed the LIS2DH sample did not have assert enabled, setting CONFIG_ASSERT=y replicated the assertion fail without the proper int-gpio-config setting. Seems to run just fine without the assert.

[Øyvind]

JyriLehtinen are you working on the same application as NautDesigner ? If so, have you been able to solve the issue?

[JyriLehtinen]

No, we're not working together.
We solved our problem with the int1-gpio-config -parameters as described above.

[Øyvind]

JyriLehtinen Thanks for clarifying!

 NautDesigner  have you had any success in finding a solution over the summer break? Could the solution be similar to the suggestion above?

[NautDesigner]

We are still getting the error when we turn assert back on. We are using the LIS2DH as well. It appears to happen on another interrupt but here are the additions we made to devicetree. Is this correct?

lis2dh: lis2dh@18 {
compatible = "st,lis2dh";
reg = <0x18>;
irq-gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>,
<&gpio0 30 GPIO_ACTIVE_HIGH>;
int1-gpio-config = <LIS2DH_DT_GPIO_INT_EDGE_BOTH>;
int2-gpio-config = <LIS2DH_DT_GPIO_INT_EDGE_BOTH>;
disconnect-sdo-sa0-pull-up;
};

[JyriLehtinen]

What a coincidence
Perhaps the issue is only in the LIS2DH driver.

Anyhow, change int1-gpio-config to <LIS2DH_DT_GPIO_INT_HIGH> (translates to value 3), that is actually more correct way for the interrupt trigger anyway, as if it remains high after processing the interrupt without ever falling down, there could be another interrupt to process. This should probably never happen but *in theory*...