why the timer callback can't be called in a loop?

RE: why the timer callback can't be called in a loop?

zk017 — Tue, 25 Jun 2019 01:07:22 GMT

it's hasn't any other interrupt at this time.

RE: why the timer callback can't be called in a loop?

zk017 — Tue, 25 Jun 2019 00:57:55 GMT

static volatile uint32_t nrf_ms_ticks = 0; and only be used in the following functions:

static volatile uint32_t nrf_ms_ticks = 0;
int nrf_ticks_get(unsigned long *tick)  
{
    *tick = nrf_ms_ticks;
	//NRF_LOG_PRINTF("%s %d\n", __FUNCTION__, nrf_ms_ticks);
	return 0;
}


//-----------------------------------------------------------------
static void nrf_tick_event_handler(void * p_context)
{
	UNUSED_PARAMETER(p_context);
	nrf_ms_ticks++;
	//NRF_LOG_PRINTF("%s\n", __FUNCTION__);
}

RE: why the timer callback can't be called in a loop?

mark_l — Mon, 24 Jun 2019 11:52:53 GMT

How is nrf_ms_ticks declared?

RE: why the timer callback can't be called in a loop?

zk017 — Mon, 24 Jun 2019 05:52:30 GMT

Yes， I found the log in while, NRF_LOG_PRINTF("stop_cup_then_home, interval_len=%d\n ", interval_len); always printed the same value, this can verify the nrf_tick_event_handler havn't executed. and some time passed, system restarted, which meet the watch dog 's function，havn't feed the watch dog resulted system restart.

RE: why the timer callback can't be called in a loop?

mark_l — Fri, 21 Jun 2019 13:46:43 GMT

How are you determining it isn't running? via the log prints? your while loop is heavily spamming the log, potentially blocking anything else from running or printing, depending on the output channel for the log data. Try taking the log print out of the while loop to see what happens. Also how is nrf_ms_ticks defined? Has it been declared as volatile?

RE: why the timer callback can't be called in a loop?

Jared — Fri, 21 Jun 2019 12:57:18 GMT

Hi,

It's difficult to tell what the issue is without reproducing the issue myself. What priorities does the timer interrupts have? The application will not handle an interrupt immediately if it's already handling another interrupt with the same priority. The interrupt will be handled after it has returned from the first.

regards

Jared