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

[dragilla]

Ok. I increased the size of the queue by 1, as it migh happen that it could overfill in deed.For now it seems to wok fine. Thanks.

[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?

[dragilla]

To be fair the impulse on the GPIOTE input pin could (i guess) happen more oftern than 100 times per second. This signal comes from zero crossing detection of a AC current (50hz). It is izolated by an octocoupler, but I guess if there is some noise in AC the timer could overlap, I mean - new signal to start the time could come before the timer expires. But then again - this theoretically should be no problem.

What if there is noise on the power supply of the NRF51 dongle. I provide the 3V3 to it from a regulated power supply that is again, powered from the same AC network (230VAC -> 3V3 DC). Can this cause problems? 

I lack some tools to make sure the power source is rock solid to eliminate this for now. Just looking for 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.

[dragilla]

Ok. Thanks. So for the app_timer I should set the priority of RTC1 to the same as GPIOTE. 

Btw. I even had the #define RTC1_ENABLED 0. Hm.... I changed it to 1 and incfeased the priority to match the one of GPIOTE. Hope this solves the issue. Thanks.