0

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

rogerclark gravatar image

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

updated 2017-08-15 00:50:01 +0100

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 flag offensive close delete report spam

Comments

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)

Roger Clark ( 2017-08-13 13:32:40 +0100 )editconvert to answer

2 answers

Sort by ยป oldest newest most voted
0
rols gravatar image

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

rogerclark gravatar image

updated 2017-08-13 23:15:33 +0100

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.

edit flag offensive delete publish link more

Comments

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

Roger Clark ( 2017-08-13 23:19:17 +0100 )editconvert to answer
0
rogerclark gravatar image

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

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.

edit flag offensive delete publish link more

Comments

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.

RK ( 2017-08-14 00:43:28 +0100 )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

Roger Clark ( 2017-08-14 01:20:00 +0100 )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)

Roger Clark ( 2017-08-15 01:00:41 +0100 )editconvert to answer

Your Answer

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

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

Question Tools

1 follower

Stats

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

Seen: 115 times

Last updated: aug. 15