sys_clock_tick_get problem

[kahlenberg]

Hi,

I want to get the tick count of the system with sys_clock_tick_get(). I am using a library for NFC reader chip ST25R3916B and provided library from STM requires a platform-dependent tick function to get the number of ticks each ms. I found sys_clock_tick_get function in nRF Connect SDK and together with k_ticks_to_ms_ceil64, I can convert it to number of ticks.

In main function, I can call it and print the result of sys_clock_tick_get in the console. But when this function gets called from a GPIO ISR, then I receive following error:

ASSERTION FAIL @ WEST_TOPDIR/zephyr/kernel/sem.c:136
E: r0/a1: 0x00000004 r1/a2: 0x00000088 r2/a3: 0x00000000
E: r3/a4: 0x0000b185 r12/ip: 0x80000000 r14/lr: 0x00010e77
E: xpsr: 0x6900001d
E: Faulting instruction address (r15/pc): 0x00014710
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Fault during interrupt handling

What causes this problem?

Thanks.

[ladybug]

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

[kahlenberg]

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.