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

asked 2017-08-13 13:21:16 +0200

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

edit retag close delete

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 ...(more)

( 2017-08-13 13:32:40 +0200 )editconvert to answer

Sort by » oldest newest most voted

answered 2017-08-13 13:34:58 +0200

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.

more

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

( 2017-08-13 23:19:17 +0200 )editconvert to answer

answered 2017-08-14 00:23:47 +0200

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.

more

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.

( 2017-08-14 00:43:28 +0200 )editconvert to answer

@RK

Thanks

You are right...

Changing this has not fixed the problem :-(

So I'll need to check if its a power /voltage issue.

Its strangely intermittent.

It can start to work, OK, even if I upload or reset the board multiple times

But if I unplug and put it on its battery, it fails again, and does not start working again when I put it back on the PSU from the PC.

On the PC I have a 1A regulator from the 5V, so it won't be short of current

( 2017-08-14 01:20:00 +0200 )editconvert to answer

I've now attached an oscilloscope across the battery on this device, and I think the problem is the CR2477 battery can't supply the necessary current to run the buzzer device that was fitted by the manufacturer :-(

On the scope I see the voltage drops to 1.6V in the worst case, (below the minamum for the nRF51)

The strange thing is,that the CPU side of the nRF51 seems to be running OK. Because after 30 second an application timer fires and my code disconnects so that the device does not get permanently left turned but idle. However, I do not get a disconnection notification either in the nRF51 code or from the Android end.

iOS seems to be different. If I try to write to the device, iOS immediately notices even though the characteristic is WriteWithoutResponse.

I will need to replace the buzzer with a lower current ...(more)

( 2017-08-15 01:00:41 +0200 )editconvert to answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

[hide preview]

## Recent blog posts

• ### ble_app_hrs_freertos running in Atollic TrueSTUDIO

Posted 2017-08-14 02:55:30 by jmag999
• ### OLED display support for nRF52832 (SSD1306, Adafruit GFX)

Posted 2017-08-11 08:21:31 by Mahesh Venkitachalam
• ### I tried 5 different debugger IDEs for nRF52 and STM32. Here are my results.

Posted 2017-08-09 10:56:19 by Jonathan
• ### Things you should know about Bluetooth mesh

Posted 2017-08-07 12:37:22 by Eirik Midttun
• ### Support pairing on NUS profile for Central and Peripheral

Posted 2017-08-01 08:42:41 by Eugene Yu

## Recent questions

• ### getting incorrect output using the timer_example_timer_mode example

Posted 2017-08-16 23:21:55 by Nikhil
• ### Sampo S1 simple "read, notify" protocol/bytestream example

Posted 2017-08-16 21:33:31 by Christian
• ### How to get softdevice state in my application

Posted 2017-08-16 20:54:24 by ypearson
• ### nRF Cloud Gateway Error connecting gateway

Posted 2017-08-16 20:05:14 by carlos carrizosa
• ### nrf52 GPIO sink & source current

Posted 2017-08-16 19:04:24 by dingari

## Stats

Asked: 2017-08-13 13:21:16 +0200

Seen: 60 times

Last updated: 2 days ago