Timer1 configuration of prox_reporter causes dramatic power increase

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at https://www.dialog-semiconductor.com/support . We’ll be fixing bugs / optimising the searching and tagging over the coming days.
5 posts / 0 new
Last post
andrewl
Offline
Last seen: 1 year 6 months ago
Joined: 2020-11-05 02:45
Timer1 configuration of prox_reporter causes dramatic power increase

Hi, folks,

 

I can set the prox_reporter project to do advertising timeout and go to extended sleep.  This is fine--the advertising does a couple of bursts and then goes to extended sleep.  I get somewhere around 1.6uA of current or so.

 

However, if I set "CFG_EXT_SLEEP_WAKEUP_TIMER1" and change *nothing else*, I get mA spikes at the advertising interval and it never stops.  That's no good.  It seems like timer1 is resetting the fact that the advertising is supposed to have timed out.

 

How do I avoid that?

 

Thanks.

 

 

Device: 
andrewl
Offline
Last seen: 1 year 6 months ago
Joined: 2020-11-05 02:45
 

 

Okay, enabling Timer1 with CFG_EXT_SLEEP_WAKEUP_TIMER1 really doesn't do what I want.  Timer1 only runs once advertising stops and then it immediately wakes up the BLE system.

What I want is Timer1 running *always* whether BLE is advertising, running, or anything else.  I want to toggle a GPIO roughly every 15/16ms no matter what is going on with BLE, non-BLE, active, extended sleep, etc.  And I *don't* want Timer1 to actually cause the BLE to restart.

So, the questions become:

1) I set a timer1_flag in timer1_interrupt_handler when it fires and then call app_resume_system_from_sleep().  Is that the correct thing to do?

2) I need to adjust the reload_val in configure_timer1_wakeup--I set it to 16.  This is the first weirdness I hit.  No matter what value I set the reload_value to, my oscilloscope shows that my handler in app_resume_system_from_sleep() triggers at somewhere between 140.944ms to 140.952ms.  Why is the reload_value having no effect? Edit: timer1 was configured with TIM1_FREE_RUN_ON which ignores reload_val. Switching to TIM1_FREE_RUN_OFF fixed this issue.

3) I have to add a handler somewhere that eventually looks for the timer1_flag.  I added it to app_resume_from_sleep().  Is that the right place?

4) I have to do something to prevent BLE from waking back up.  I tried to check in app_resume_from_sleep() whether my timer1_flag got set.  If so, I skip the whole arch_ble_ext_wakeup_get() code block.  However, that doesn't seem to be sufficient or it may be completely the wrong place.  If I look on my Keithley SourceMeter, I see the system pulling roughly 14uA of current in 1second bursts with a quiet period of 4 seconds.  That looks exactly like my advertising parameters (1sec/5sec), so I'm still doing something which sets off the BLE system.  How do I stop that?

 

Thanks.

PM_Dialog
Offline
Last seen: 6 months 3 weeks ago
Staff
Joined: 2018-02-08 11:03
Hi andrewl,

Hi andrewl,

The timer1 is configured when the advertisement has been stopped after a predefined amount of time – see .advertise_period  and . adv_scenario in user_config file.

When the device stops advertising, the app_advertise_complete() callback is triggered and the timer1 configuration takes place - configure_timer1_wakeup().

If you check the count_options configuration structure, you will see that the timer1 reload value is set to TIM1_RELOAD_MAX ( 11 bits ). Additionally, the input clock is the Low Power Clock and specifically the internal RCX (see CFG_LP_CLK macro in da1458x_config_advanced.h)

Given that, the timer1_interrupt_hdlr() will be triggered every : (1/15000) * 2^11 ~= 0.1365 sec or 136.5 msec.

When the timer1_interrupt_hdlr() is triggered, then the system resumes from sleep state.

>>I want to toggle a GPIO roughly every 15/16ms no matter what is going on with BLE, non-BLE, active, extended sleep, etc.  And I *don't* want Timer1 to actually cause the BLE to restart.

Probably you could change the timer1 reload value and in the timer1_interrupt_hdlr() toggle the GPIO

In the prox_reporter example of the SDK, the timer1 is being used to wake up the DA14531 from sleep mode. So, my recommendation would be to start with the empty_peripheral_template and port the Timer1 configuration in this project.

Thanks, PM_Dialog

andrewl
Offline
Last seen: 1 year 6 months ago
Joined: 2020-11-05 02:45
The issue is that when the

The issue is that when the system exits the sleep state for any reason, it starts advertising again.  Thus, enabling Timer1 which is a max of 136.5ms effectively makes it so that the system never leaves advertising mode.

PM_Dialog
Offline
Last seen: 6 months 3 weeks ago
Staff
Joined: 2018-02-08 11:03
Hi andrewl,

Hi andrewl,

As mentioned in my previous comments, the timer1_interrupt_hdlr() will fire up after ~136.5 msec when the advertisement has been stopped. So, the chip will sleep for ~136.5 msec and then it will wake up again.

Thanks, PM_Dialog