v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

JyriLehtinen — Thu, 15 Aug 2024 13:29:03 GMT

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*...

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

NautDesigner — Thu, 15 Aug 2024 13:24:50 GMT

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;
};

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

Øyvind — Thu, 15 Aug 2024 06:46:52 GMT

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?

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

JyriLehtinen — Wed, 14 Aug 2024 07:50:24 GMT

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

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

Øyvind — Wed, 14 Aug 2024 07:30:07 GMT

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

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

JyriLehtinen — Tue, 30 Jul 2024 12:47:04 GMT

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.

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

JyriLehtinen — Thu, 25 Jul 2024 05:58:31 GMT

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.

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

NautDesigner — Fri, 12 Jul 2024 09:41:32 GMT

static const struct gpio_dt_spec status = GPIO_DT_SPEC_GET_OR(SW3_NODE, gpios, {0});
gpio_pin_configure_dt(&status, GPIO_INPUT);

void statusCallback(const struct device *dev, struct gpio_callback *cb, uint32_t pins) {

//printk("*****\nCallback\n*****\n");
   if (gpio_pin_get_dt(&status)) {
      setStatusLED(true);
      //printk("** Status LED On **\n");
   } else {
      setStatusLED(false);
      //printk("** Status LED Off **\n");
   }
//printk("* Leaving callback *\n");
}

   int ret = gpio_pin_interrupt_configure_dt(&status, GPIO_INT_EDGE_BOTH); // edge falling is just an example.. you should set it what you need it to be
   if (ret != 0) {
      printk("Error %d: failed to configure interrupt pin %d\n", ret, status.pin);
   } else {
      gpio_init_callback(&fix_cb, statusCallback, BIT(status.pin));
      gpio_add_callback(status.port, &fix_cb);
   }

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

Øyvind — Fri, 12 Jul 2024 07:23:37 GMT

Thanks for sharing.

From \zephyr\include\zephyr\drivers\gpio.h

/**
 * @brief Configure pin interrupts from a @p gpio_dt_spec.
 *
 * This is equivalent to:
 *
 *     gpio_pin_interrupt_configure(spec->port, spec->pin, flags);
 *
 * The <tt>spec->dt_flags</tt> value is not used.
 *
 * @param spec GPIO specification from devicetree
 * @param flags interrupt configuration flags
 * @return a value from gpio_pin_interrupt_configure()
 */
static inline int gpio_pin_interrupt_configure_dt(const struct gpio_dt_spec *spec,
						  gpio_flags_t flags)
{
	return gpio_pin_interrupt_configure(spec->port, spec->pin, flags);
}

[quote user="NautDesigner"]int ret = gpio_pin_interrupt_configure_dt(&status, GPIO_INT_EDGE_BOTH);[/quote]

What is &status pointing to in your case?

Are you able to share more of your code around the interrupt configuration?

Thanks.

-Øyvind

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

NautDesigner — Wed, 10 Jul 2024 13:52:51 GMT

int ret = gpio_pin_interrupt_configure_dt(&status, GPIO_INT_EDGE_BOTH);

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

Øyvind — Wed, 10 Jul 2024 13:46:02 GMT

How are you calling gpio_pin_interrupt_configure() i.e. what flags are you setting. This seems to be due to given function not having either GPIO_INT_DISABLE or GPIO_INT_ENABLE.

Kind regards,
Øyvind

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

NautDesigner — Tue, 09 Jul 2024 09:40:33 GMT

> D:\ncs\toolchains\cf2149caf2\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-addr2line.exe -e .\build\zephyr\zephyr.elf 0x00045d93
D:/ncs/v2.6.1/zephyr/include/zephyr/drivers/gpio.h:883

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

Øyvind — Tue, 09 Jul 2024 09:23:58 GMT

[quote user=""]ASSERTION FAIL @ WEST_TOPDIR/zephyr/include/zephyr/drivers/gpio.h:883[/quote]

The line it is referring to in this file is:

__ASSERT((flags & (GPIO_INT_DISABLE | GPIO_INT_ENABLE)) != 0U,

"Must either enable or disable interrupts");

Line 44 in assert.c does not provide any good information, other than k_panic().

Could you run addr2line on address 0x00045d0b as well?

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

NautDesigner — Tue, 09 Jul 2024 09:04:10 GMT

Deleted all build folders and rebuilt the application.

D:\ncs\toolchains\cf2149caf2\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-addr2line.exe -e .\build\zephyr\zephyr.elf 0x000668c2
D:/ncs/v2.6.1/zephyr/lib/os/assert.c:44

RE: v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

Øyvind — Tue, 09 Jul 2024 07:35:52 GMT

Hello,

Could you please provide the output C:\ncs\toolchains\cf2149caf2\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-addr2line.exe -e /build/zephyr/zephyr.elf 0x2000fb38 in command line ? Make sure to point to correct path of your toolchain folder cf2149caf2.

If this does not work, please try with address 0x00045d0b

This should give some indication of what is causing this fatal error. What happens if you remove the build folder completely?

Kind regards,
Øyvind