Do Long delays in main loop cause problems? (possible brownout problem)

[Roger Clark]

I'm using nrf_delay_ms to trigger a series of beeps though a speaker using PWM, but I seem to have intermittent problems with this when the device is connected.

Basically my Android app, connects to the "beacon" and write to a characteristic with a command that makes the beacon beep, so that it can be found by listening to the sound.

In the write data handler I use the app scheduler to call the findMeBeeps function

app_sched_event_put(0,0,(app_sched_event_handler_t)findMeBeeps); 


void findMeBeeps(void)
{
	for(int i=0;i<5 ;i++)
	{
		if (i!=0)
		{
			nrf_delay_ms(250);
		}
		beep(250);
	}
}

the beep function turns on PWM to one of the pins, calls nrf_delay_ms and then turns pwm off again (and de-inits the PWM to stop the pin drawing any current)

So overall the 5 beeps take 2.5 second to complete and block the main loop while this is running.

Unfortunately, what seems to happen sometimes, is that I can't repeatedly send the command to play the beeps.

The Android app thinks its written to the characteristic, but the on_write function for the characteristic does not seem to receive the data.

Whats even stranger, is that sometimes I compile the code and it works fine, over and over again, and some other times, I compile the code and it will only play the beeps once.

So...

I don't know whether the problem is that I can't lock up the main loop for that long.

BTW. I have tried loads of other things to work out whats going on...

I tried just printing "Beep" to the debug terminal and this worked OK.

I also at one point changed the pin, so that I was not actually driving the speaker/buzzer, in case that was an issue, because the speaker/buzzer is drive via transistor and takes around 100mA. And at the time that seemed to work OK,

but as its all so intermittent, its hard to know if any of these changes yielded the result because of the change or just randomness.

Because currently I can beep 50 beeps of 50ms and thats also working perfectly.

But I"m sure tomorrow when I turn it on and compile in some more code it could go back to failing again

[RK]

In general you can lock up the main loop as long as you like. It's running at the lowest priority possible so the softdevice and every kind of interrupt handler out there interrupts it whenever it wants. So you're not really blocking anything.

If you have time-sensitive code in your loop, that might be an issue. If you have an interrupt which is higher priority than softdevice low priority and that REALLY drags, you might cause issues, but apart from that, it's pretty hard to mess it up.

Consider that the default no-sleep main loop is often written as

while(1)
    ;

and that works fine - you can see a main loop which just burns electrons isn't really a problem.

[Roger Clark]

Thanks. I will rule out hogging the main loop as the problem.