Large delay between k_signal_raise and k_poll invocation

[GuyYaniv]

Hi,

I'm using an nrfx_timer event with k_poll_signal_raise to trigger a thread to perform an operation.

I've noticed around 900ms delay between when the signal is raised and the k_poll runs in the thread.

This is observed using a logic analyzer with logging level error.

I cannot explain where this delay is coming from. I used systemview tracing and also used the user tracer with my own traveller to find out what is running during this time and it only shows system idle task running.

I'm out of ideas and wanted to see if you've encountered anything similar? Here's the code snippet of what I'm trying to do:

/*
* get power eading thread handler
*/
void get_power_reading_hdl(void *p1, void *p2, void *p3) {
    int signaled, result;

    while (k_poll(power_evt, 1, K_FOREVER)==0) {

nrf_gpio_pin_clear(TAT_TOGET_PWR);
        k_poll_signal_check(&get_power_sig, &signaled, &result);
        if (signaled == 0) {
            LOG_ERR("ERROR false signal");
            return;
        }
        k_poll_signal_reset(&get_power_sig);
        power_evt[0].state = K_POLL_STATE_NOT_READY;

        while ((tat_data.t_hash > 1) && (((1<<tat_data.t_hash) & tat_data.target_address) == 0)) {
            tat_data.t_hash--;
                continue;
        }
        if (tat_data.t_hash > 1) {
            LOG_DBG("Get power reading for %x", 1<<tat_data.t_hash);
            get_power_reading(1<<tat_data.t_hash);
nrf_gpio_pin_set(GET_PWR_GAP);
            tat_data.t_hash--;
        }
        if (tat_data.t_hash>1){
            k_timer_stop(&power_reading_timeout);
            atomic_set(&in_tat_loop, 0);                        
        }
    }
}

/* 
* This is a timer handle that runs when power reading collection has been done
*/
void get_power_reading_daemon(int id) {
    /* Send the first get_power_reading command */
    k_poll_signal_raise(&get_power_sig, 0);
    reach_put_timer(tat_data.get_pwr_reading_tmr);
}

The signal is initialized at system startup.

Thanks in advance for any clue that might help,

Guy

[Vidar Berg]

Hello,

Is get_power_reading_daemon()::k_poll_signal_raise() called in the TIMER IRQ context, and in that case, are you using the IRQ_CONNECT() macro to register the ISR? I wondering if the delay could be caused by the scheduler is not being run immediately after exiting the ISR. 

    IRQ_CONNECT(NRFX_IRQ_NUMBER_GET(NRF_TIMER_INST_GET(TIMER_INST_IDX)), IRQ_PRIO_LOWEST,
                NRFX_TIMER_INST_HANDLER_GET(TIMER_INST_IDX), 0, 0);

Best regards,

Vidar

[GuyYaniv]

Hello Vidar,

Yes, get_power_reading_daemon() is called from the event handler registered by nrfx_timer_init().

And yes I am using IRQ_CONNECT() for that interrupt:

void reach_timer_init() {
    nrfx_err_t err;

    config.bit_width = NRF_TIMER_BIT_WIDTH_32;

    err = nrfx_timer_init(&timestamp, &config, timestamp_event_handler);
    if (err != NRFX_SUCCESS) {
        LOG_ERR("Error initializing timer %x", err);
    }

    IRQ_DIRECT_CONNECT(TIMER4_IRQn, IRQ_PRIO_LOWEST, nrfx_timer_4_irq_handler, 0);

    nrfx_timer_pause(&timestamp);
    nrfx_timer_clear(&timestamp);
    nrfx_timer_compare(&timestamp, NRF_TIMER_CC_CHANNEL0, 0xFFFFFFFF, true);
    NVIC_EnableIRQ(TIMER4_IRQn);
    irq_enable(TIMER4_IRQn);

    nrfx_timer_enable(&timestamp);
}

How can I verify that the scheduler does indeed run after the ISR, and what might cause that condition to happen?

Thanks,

Guy.

[Vidar Berg]

Hello Guy,

Thanks for confirming. So I see you are using IRQ_DIRECT_CONNECT() macro instead of IRQ_CONNECT(): https://github.com/zephyrproject-rtos/zephyr/commit/4fc96066b025f9e4ffcd1b244d460c7338d3099b. Please try with the line below instead.

IRQ_CONNECT(TIMER4_IRQn, IRQ_PRIO_LOWEST, nrfx_timer_4_irq_handler, NULL, 0);

 

Best regards,

Vidar

[GuyYaniv]

That did the trick! Thank you!

Can you please explain why would one present this behavior as opposed to the other?

Thanks,

Guy.

[Vidar Berg]

Excellent! Yes, the regular Zephyr ISR will automatically trigger the PendSV exception on exit to wake up the scheduler and check for pending tasks. If PendSV is not triggered, program execution will just return to where it was prior to the interrupt (the idle thread in your case). It is possible to do the same with 'direct' interrupts, but then you must declare your own ISR as mentioned in the linked commit.