This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

  • Just to update this.

    I think perhaps this is some sort of power problem.

    I powered the device from a 3V 1000mAH lithium cell, and tried again, and the problem returned, even though I had not uploaded any new code.

    I put it back in the bench power supply, but the problem still persists

    Which is very odd.

    The beeper does not seem to completely crash the device, because I have a 30 second timer running, which I use to close open connections to the Android app, in case the android app does not auromatically close the connection.

    So after 30 secs the connection is closed and I can press the button on the App again, to send the command to beep, and it works - just once

    I will probably unsolder the beeper off one board and replace it with a LED send see if it still has this strange behaviour

    PS. I forgot to say I'm using a nRF51822 custom board, with SDK 12.3

  • 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.

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

  • I think I found a bug in my code which is potentially causing the problem

    void findMeBeeps(void) 
    

    should be

    void findMeBeeps(void * p_event_data, uint16_t event_size)
    

    So there would be junk left on the stack which sometimes caused the system some problems

    I'm not sure if this totally fixes the problem or whether there is something else wrong.

    But that code was definitely wrong.

  • no there wouldn't be junk left on the stack, the pre- and post- code would put the stack back exactly as it was before the call. However if your declaration and definition were different and the code actually tried to use that data in those parameters, it would read rubbish out of r0 and r1.

Related