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

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

Roger Clark — Mon, 14 Aug 2017 23:00:41 GMT

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 device, but I thought I'd post the resolution in case it helps anyone.

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

Roger Clark — Sun, 13 Aug 2017 23:20:00 GMT

@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

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

RK — Sun, 13 Aug 2017 22:43:28 GMT

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.

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

Roger Clark — Sun, 13 Aug 2017 22:23:47 GMT

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.

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

Roger Clark — Sun, 13 Aug 2017 21:19:17 GMT

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

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

RK — Sun, 13 Aug 2017 11:34:58 GMT

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.

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

Roger Clark — Sun, 13 Aug 2017 11:32:40 GMT

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