Device restarting for no obvious reason

[dragilla]

Hi, 

When I connect my device to an external power supply, it restarts randomly. It sometimes happens once every minute, sometimes once every 10 minutes. I couldn't find a pattern. 

Is there a way to figure out the reason somewhere in the software? I'm almost sure this is not a 100% HW issue, I changed a lot of things today in the SW only, and yesterday the device was not restarting :( However, when I just power it from the USB it does not restart.

Please, give me some advice. I will try to change the power supply but for now I only have one.

Thanks

[Jørgen Holmefjord]

Hi,

See this post.

You can also check the reason for a reset in the RESETREAS register, in case this is caused by HW issue and not a soft reset executed by software.

Best regards,
Jørgen

[dragilla]

Ok. This is strange. I increased the queue size. I also added a variable to minitor the queue size and i increase them just after calling the timer_start functions and I decrease it once I get NRF_SUCCESS. Also - I only have one, single-shot time that I start based on an interrupt (LOW_TO_HIGH transisition on one of the GPIOS). This interrupt happens 100 times per second, but as I read in the docs, if the timer is started and I start it agin, the call should just be ignored, right?

Even so, I get to the point where my app stops in the infinite loop in the app_error.c and my timer_queue_size is just "1". In init I set te size to 5. The err_code is still 4 - and the error happens in the in_pin_handler func.

My code for the starting part:

void in_pin_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{	
    uint32_t err_code;
		//app_trace_log("zero crossing detected\r\n");
	
		// wait for calculated time	and fire the triac
		if(triac_on) 
		{
				if(global_delay > 0) {
						nrf_drv_gpiote_out_clear(PIN_OUT);
						err_code = app_timer_start(TRIAC_ONOFF, global_delay, NULL);
						timer_queue_size ++;
						APP_ERROR_CHECK(err_code);
						timer_queue_size --;
				}
		} 
		else 
		{ 
				nrf_drv_gpiote_out_clear(PIN_OUT);
		}
}

Any ideas?

[Jørgen Holmefjord]

The call to app_timer_start will still schedule an operation inside app_timer, but the operation should be ignored when it is processed.

When scheduling the operation, app_timer will set a pending software interrupt (SWI), and the operations will be handled in the software interrupt handler. If you call app_timer_start from a higher interrupt priority than app_timer runs at, the software interrupt will not run until you have exited the handler where the function was called from, even if you get a NRF_SUCCESS return code. If you have very frequent interrupts from GPIOTE, and these have higher priority than app_timer, the operations may queue up if you do not have enough CPU-time to execute the app_timer software interrupt.

What priority are you running GPIOTE at? If you run this at the same priority as app_timer (defaults to APP_IRQ_PRIORITY_LOW), the pending interrupt should be executed before the next GPIOTE interrupt is serviced.