Wake up main thread on any interrupt

Hi,

Is there a way to make the main thread to execute after any interrupt? 

For now, I have something like this (ncs 2.7.0): 

in main thread : 

for(;;)
{
    // execute code
    k_sleep(K_FOREVER);
}

In each IRQ handlers (gpio, timers...) 

irq_handler
{
    k_wakeup(mainThreadID);
}

I think that this is error prone, as I can't be sure to fill all handlers, and it could be hard to maintain. Also, what about the native handler I didn't overwrite? 

Is there a way to have a general irq_handler or a hook that could be executed on ANY interrupt, in addition to other regular handlers?

The whole point here is to replace the WFE() instruction I had in a bare metal application.

Thank you for your help

Parents
  • You should be able to use thread suspend and resume as mentioned in this Zephyr documentation to achieve what you want.

    The template code can be something like below

    static struct k_thread *main_thread;
    
    void main(void)
    {
        main_thread = k_current_get();  // Get the main thread handle
    
        for (;;) {
            k_thread_suspend(main_thread);  // Suspend the thread
            ...  // whatever logic you want to continue here if any
        }
    }
    
    And in the irq handler you can do below
    void irq_handler(const struct device *dev, struct gpio_callback *cb, uint32_t pins)
    {
        printk("Interrupt Triggered!\n");
    
        // Resume the main thread
        k_thread_resume(main_thread);
    }
    

  • Hi, thank you for your answer, I will try it, but it doesn't adress the question of an existing general irq_handler. It would be great to have this to be sure to not miss any event (the same way WFE() would not miss any event either).

    [EDIT]  either I use k_sleep/k_wakeup, semaphores or k_thread_suspend/k_thread_resume, it takes 10s for the main thread to execute after the wakeup. here is what I do

    -the main thread run a custom scheduler that pop event from a fifo

    -the main thread goes to sleep or same take or suspend

    -the different irq do a k_wakeup / give the semaphore / k_thread_resume

    -the main thread is supposed to resume right away, but takes 10s. 

    here is the logs with a timestamp like this [time_ms] : 

    [090135]  DIR/app/main:462 m_t
    [090135]  f5340/drv_ble_stack:33 bt
    [090136]  f5340/drv_ble_stack:33 bt
    [090136]  f5340/drv_ble_stack:33 bt
    [090137]  f5340/drv_ble_stack:33 bt
    [090137]  f5340/drv_ble_stack:33 bt
    [090138]  f5340/drv_ble_stack:33 bt
    [090139]  f5340/drv_ble_stack:33 bt
    [090139]  f5340/drv_ble_stack:33 bt
    [090661]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [091861]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [093061]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [094261]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [095461]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [096662]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [097862]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [099062]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [100140]  DIR/app/main:462 m_t
    [100140]  f5340/drv_ble_stack:33 bt
    [100141]  f5340/drv_ble_stack:33 bt
    [100142]  f5340/drv_ble_stack:33 bt
    [100142]  f5340/drv_ble_stack:33 bt
    [100143]  f5340/drv_ble_stack:33 bt
    [100143]  f5340/drv_ble_stack:33 bt
    [100144]  f5340/drv_ble_stack:33 bt
    [100144]  f5340/drv_ble_stack:33 bt

    "m_t" is when main thread is executed

    "bt" is a BLE action that the main thread execute when needed

    Every 1.2s, the RTC trigger an irq as exepected, and is supposed to wake up the main thread to execute a BLE action.

    But we see that the main thread does not  wake up before 10s, and then pop all BLE actions.

    Why does the main thread not waking up right away? 

    Thank you for your help

Reply
  • Hi, thank you for your answer, I will try it, but it doesn't adress the question of an existing general irq_handler. It would be great to have this to be sure to not miss any event (the same way WFE() would not miss any event either).

    [EDIT]  either I use k_sleep/k_wakeup, semaphores or k_thread_suspend/k_thread_resume, it takes 10s for the main thread to execute after the wakeup. here is what I do

    -the main thread run a custom scheduler that pop event from a fifo

    -the main thread goes to sleep or same take or suspend

    -the different irq do a k_wakeup / give the semaphore / k_thread_resume

    -the main thread is supposed to resume right away, but takes 10s. 

    here is the logs with a timestamp like this [time_ms] : 

    [090135]  DIR/app/main:462 m_t
    [090135]  f5340/drv_ble_stack:33 bt
    [090136]  f5340/drv_ble_stack:33 bt
    [090136]  f5340/drv_ble_stack:33 bt
    [090137]  f5340/drv_ble_stack:33 bt
    [090137]  f5340/drv_ble_stack:33 bt
    [090138]  f5340/drv_ble_stack:33 bt
    [090139]  f5340/drv_ble_stack:33 bt
    [090139]  f5340/drv_ble_stack:33 bt
    [090661]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [091861]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [093061]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [094261]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [095461]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [096662]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [097862]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [099062]  t/nrf5340/drv_timer:79 RTC0_IRQHandler
    [100140]  DIR/app/main:462 m_t
    [100140]  f5340/drv_ble_stack:33 bt
    [100141]  f5340/drv_ble_stack:33 bt
    [100142]  f5340/drv_ble_stack:33 bt
    [100142]  f5340/drv_ble_stack:33 bt
    [100143]  f5340/drv_ble_stack:33 bt
    [100143]  f5340/drv_ble_stack:33 bt
    [100144]  f5340/drv_ble_stack:33 bt
    [100144]  f5340/drv_ble_stack:33 bt

    "m_t" is when main thread is executed

    "bt" is a BLE action that the main thread execute when needed

    Every 1.2s, the RTC trigger an irq as exepected, and is supposed to wake up the main thread to execute a BLE action.

    But we see that the main thread does not  wake up before 10s, and then pop all BLE actions.

    Why does the main thread not waking up right away? 

    Thank you for your help

Children
No Data
Related