RE: sys_clock_tick_get problem

kahlenberg — Sat, 25 May 2024 18:43:39 GMT

Thank you very much. I redesigned my code, I created a work item and in ISR I submit work item to the system queue. I don't get the error anymore and code works as expected.

RE: sys_clock_tick_get problem

kahlenberg — Sat, 25 May 2024 18:42:29 GMT

Thank you for testing, but I solved the problem by creating a work queue and submit a work in ISR.

RE: sys_clock_tick_get problem

Naeem Maroof — Fri, 24 May 2024 14:04:30 GMT

Hi Mubin,

I am not sure what your project looks like, but I would suggest you do some debugging.

I can call that function in the button callback as below:

RE: sys_clock_tick_get problem

ladybug — Thu, 23 May 2024 09:58:42 GMT

The error you're encountering, a kernel panic with assertion failure during interrupt handling, suggests that there's an issue with how the `sys_clock_tick_get()` function is being called from within the GPIO ISR.

Interrupt service routines (ISRs) in Zephyr have certain constraints and limitations, and calling certain functions, especially those that involve synchronization primitives like semaphores, from within an ISR can lead to unpredictable behavior, including kernel panics.

Here are a few potential causes and solutions:

1. Interrupt Context Safety: Ensure that the `sys_clock_tick_get()` function is safe to call from within an ISR. Check the documentation or implementation details of the function to see if it explicitly states whether it's ISR-safe.

2. Blocking Calls: Avoid making blocking or long-running calls from within ISRs. If `sys_clock_tick_get()` or any function it calls internally involves blocking operations or takes a significant amount of time to execute, it should not be called from within an ISR.

3. Synchronization Primitives: The assertion failure in `sem.c` suggests that there might be an issue related to semaphore usage. If `sys_clock_tick_get()` or any function it calls internally attempts to acquire or release a semaphore, it should not be called from within an ISR. Consider redesigning your code to avoid such dependencies from within ISRs.

4. Critical Sections: If `sys_clock_tick_get()` involves accessing shared resources that may be modified concurrently by other ISRs or the main execution context, consider using appropriate locking mechanisms such as disabling interrupts (`irq_lock()` and `irq_unlock()`) or using atomic operations (`atomic_*` functions) to protect critical sections of code.

5. Debugging: Review the stack trace and analyze the execution context leading up to the kernel panic. Identify any potential sources of contention or unsafe operations within the ISR or functions called from it.

By ensuring that your ISR adheres to the safety and performance guidelines outlined in the Zephyr documentation, you should be able to resolve the kernel panic issue when calling `sys_clock_tick_get()` from within the GPIO ISR. geometry dash