Enter and exit sleep mode

12 posts / 0 new
Last post
Myken
Offline
Last seen: 25 min 51 sec ago
Joined: 2016-07-13 20:06
Enter and exit sleep mode

Question about the sleep mode, I'm really confused how this should work.

if I put this in my system_init():

pm_set_wakeup_mode(true);
pm_set_sleep_mode(pm_mode_extended_sleep);

and I put this in my prvSetupHardware():

/* Initialize Wake-up timer */
hw_wkup_init(NULL);
hw_wkup_set_counter_threshold(1);
hw_wkup_set_debounce_time(10);
hw_wkup_register_interrupt(wkup_cb, 1);

Then there is nothing more to configure regarding sleep mode, right?
As soon as there is no more BLE activity the device will go to sleep mode.
And sinds I have no button as wake-up the only wake-up possible is if there is power on the VBUS.

However my device will go to sleep mode immediately after startup. Even if I have


ble_gap_adv_intv_set(BLE_ADV_INTERVAL_FROM_MS(500), BLE_ADV_INTERVAL_FROM_MS(2000));
ble_gap_adv_data_set(sizeof(adv_data), adv_data, 0, NULL);
ble_gap_adv_start(GAP_CONN_MODE_UNDIRECTED);

configured in my ble_peripheral_task().
BTW I use the dk_apps/features/ble_peripheral/ as template for my project.

So as far as I know there should be BLE activity but the device enters sleep mode.

What am I missing?

Device: 
SDK: 
MT_dialog
Offline
Last seen: 23 min 25 sec ago
Staff
Joined: 2015-06-08 11:34
Hi Myken,

Hi Myken,

Are you sure that what you see is sleeping, and not that the device is stuck due to an ASSERTION ? The SDK keeps the device about 8 seconds out of sleep mode in order for the XTAL32 to settle, so upon booting up the device should stay alive for a period of 8 seconds. For the SDK to set the sleep mode on into a fw the only thing that you will have to do is to set_pm_sleep_mode(pm_mode_extended_sleep), all the other configurations that you have is just to wake up the device by a specific pin (although you haven't configured which pin, i dont see a hw_wkup_configure_pin() function in order to specify a pin for the interrupt), and since you 've instructed the device to start advertise, then the device should start advertising in no sleep mode for the first 8 seconds and then sleep and wake up in each advertising interval.

Thanks MT_dialog

Myken
Offline
Last seen: 25 min 51 sec ago
Joined: 2016-07-13 20:06
OK, that clears it up a bit.

OK, that clears it up a bit. That leaves me with two questions:

  1. Wake-up. You are correct I don't have a wake-up pin configured (no hw_wkup_configure_pin()). The reason is, I want to wake-up using the VBUS interrupt. According to the UM-B-044-DA1468x Software Platform Reference, we can wake-up "Asynchronously, from the Wake-up timer or the VBUS interrupt". I could not find any information how to set-up this VBUS interrupt wake-up so I assumed it would be always enabled. Is this correct? And can I leave all wake-up configuration out?
  2. Assertion. pm_set_sleep_mode(pm_mode_active) works fine, pm_set_sleep_mode(pm_mode_idle) works fine. However if I program pm_set_sleep_mode(pm_mode_extended_sleep) and I RESET the device, it works fine (as far as I can tell), but when I POWER DOWN -> POWER UP it gets stuck. The assertions in the SDK check invalid parameters and missing configurations so there must be something missing if it is an assertion, question is what is missing. Are there any pre-conditions that need to be for-filled before entering the extended sleep mode?

Thanks

MT_dialog
Offline
Last seen: 23 min 25 sec ago
Staff
Joined: 2015-06-08 11:34
Hi Myken,

Hi Myken,

1) As you said the asyncronous wake up events can be either the wake up timer or the VBUS, since you would like wake up only from the VBUS this is allready configured by h/w and you dont have to set up the wake up timer. The VBUS_Handler() will occur as soon as you plug in the USB and you should also configure the device to use the USB either as charger or as data dg_configUSE_USB or dg_configUSE_USB_CHARGER and if you would like your device to perfom a specific functionallity you should notify your task via the usb_attach_cb hook.

2) I dont quite understand the case after you download code in the flash (while the device is configured in pm_set_sleep_mode) and you hit the reset, you can see the device advertising, but if you power off the device (for example plug, unplug the usb from the dev kit) the device stalls and doesn't advertise ? There is no configuration as far as i am aware that it will do that, do you get the same with the SDK examples, when you burn the flash, power off and then power on ? 

Thanks MT_dialog 

Myken
Offline
Last seen: 25 min 51 sec ago
Joined: 2016-07-13 20:06
Hello Support,

Hello Support,

  1. Thanks. I have configured to use the USB as mentioned.
  2. Correct, with one exception, it's not on a dev kit. It's on my application board. I'll switch back to the dev kit and try to work from there. I'll report back if I find anything.

Thanks.

Myken
Offline
Last seen: 25 min 51 sec ago
Joined: 2016-07-13 20:06
Hello Support,

Hello Support,

2.
Tested with the dev.kit, works fine. Tested with my application it works fine "IF" I disconnect all additional electronics from the V33 power supply.
It looks like the sleep configuration as a direct impact on the power configuration. Apparently this causes problems at start-up. The additional electronics use some power at start-up (max 20 mA) but it look like the DA1468X is not capable to deliver if it is configured as pm_set_sleep_mode(pm_mode_extended_sleep).
At pm_set_sleep_mode(pm_mode_extended_sleep) the V33 is 3.1V and very noisy.
At pm_set_sleep_mode(pm_mode_active) the V33 is 3.3V and not noisy.

So two question:
a. is there a correlation between sleep configuration and the V33? Just to clarify I don't mean the sleep mode but the sleep configuration.

b. does it work if I put the command pm_set_sleep_mode(pm_mode_extended_sleep) some where later in the code (e.g. after a timer or after the first gap connect/disconnect)?

Thanks.

Myken
Offline
Last seen: 25 min 51 sec ago
Joined: 2016-07-13 20:06
Hello Support,

Hello Support,

Now I'm really lost!!!!!

In my application I have a custom characteristic to directly write to the LED outputs. For this test I disabled all additional electronics attached to the V33 power output, so basically I have the same setup as the dev.kit.
Now I have:

  1. compiled and loaded my software with the pm_set_sleep_mode(pm_mode_active) or pm_set_sleep_mode(pm_mode_idle) both work, reset the device. At this point I'm able to connect and write to the LED characteristic => result LED ON!!!
  2. compiled and loaded my software with the pm_set_sleep_mode(pm_mode_extended_sleep), reset the device. At this point I'm able to connect and write to the LED characteristic => result NO LED reaction??????, no disconnect, no error, just no response. I can disconnect, connect again and write to the characteristic, but no response.

Now to completely make it all confusing is that in both cases (1 and 2) I can read the battery level through the battery level characteristic and in both cases the read back changes with a physical changing battery level.

Changing pm_set_sleep_mode(pm_mode_idle) => pm_set_sleep_mode(pm_mode_extended_sleep) has a huge impact on the functionality of my software, why?
What am I doing wrong?

--- EDIT ---
Did try something else:
Called pm_set_sleep_mode(pm_mode_extended_sleep) in handle_evt_gap_disconnected() so the sleep mode would become active after the first disconnect.
Then: connect, write to LED characteristic => works perfectly.
Next: disconnect, through the noisy V33 I can see that pm_mode_extended_sleep is active, BUT I also see that the LED turn OFF !!! Unable to turn it ON.

As a side note:
For the LED I have setup timer 2 as PWM and connected the LEDs using hw_led_set_led1_src(HW_LED_SRC1_PWM2). I can turn on the LED by changing the PWM duty cycle.

So calling the function pm_set_sleep_mode(pm_mode_extended_sleep) does not only prepare for extended sleep but it also disables some other functions/peripherals, timer2 in my case!?!
AND !!!! the SPI interface !!! (or at least the CS goes low) that explains why my additional electronics stopped working !!!!!!!!!!!!!
Is there any documentation regarding feature?

MT_dialog
Offline
Last seen: 23 min 25 sec ago
Staff
Joined: 2015-06-08 11:34
Hi Myken,

Hi Myken,

The sleep configuration disables the peripherals on the 68x device incuding the timer2 (only timer1 is active which powers the RTOS), you can have a look at the UM-B-044-DA1468x Software Platform Reference.pdf in order to check which parts of the device stay powered when the device goes in sleep mode. Also be aware that when the device goes in sleep mode all the rails go in low power mode and that means that the current that the device can supply when in sleep mode that is about 3mA, so the external devices hooked on V33 and V18 cannot consume more current than that. Also all the GPIOs when the device goes to sleep mode are latched to their last state and you will have to set the state of the pins when waking up in the periph_setup function, since they are re-configured.

Thanks MT_dialog  

Myken
Offline
Last seen: 25 min 51 sec ago
Joined: 2016-07-13 20:06
It must be a language thing.

It must be a language thing. But I’m confused.
I’m not a native English writer so bear with me, I don’t want to blunt, just clear.

With “the sleep configuration” I mean the pm_set_sleep_mode(pm_mode_extended_sleep); statement.

With “the device goes into sleep mode” I mean the point 5 in Figure 22: Asynchronous BLE event page 83 of the UM-B-044-DA1468x Software Platform Reference.pdf.
The device is in sleep mode at/during point 6.

I understand that peripherals stop working when de device is IN sleep mode (point 6). And that the device will go into sleep mode if there are no more BLE activities and the pm_set_sleep_mode(pm_mode_extended_sleep); statement is given to configure that action.
I do not understand that peripherals are stopped right/immediately after the pm_set_sleep_mode(pm_mode_extended_sleep); statement.

If I issue/give/activate a command through a BLE characteristic and that command calls the pm_set_sleep_mode(pm_mode_extended_sleep); statement, all peripherals are immediately disabled AND the BLE connection is terminated.
Not after 8 seconds, not after a disconnect, no immediately!
Is this intended functionality or an error?

Your last sentence I do not understand:
“Also all the GPIOs when the device goes to sleep mode are latched to their last state and you will have to set the state of the pins when waking up in the periph_setup function, since they are re-configured.”

Does this mean I have to call this periph_setup function (static void prvSetupHardware( void ) in my case) when waking up?
If I want to wake up on the VBUS_Handler() interrupt where do I do that?
The VBUS_Handler() doesn’t seam to have a user definable call-back function.

Thanks.

MT_dialog
Offline
Last seen: 23 min 25 sec ago
Staff
Joined: 2015-06-08 11:34
Hi Myken,

Hi Myken,

I think that mostly you 've misunderstood the system's functionallity when sleeping, what i understand and might be happening on your setup: 

  • The 8 seconds that the device stays active when firstly booted (even when you have configured the pm_set_sleep_mode(pm_extended_sleep), that means that the device wakes up and sleep between each connection or between each advertising interval, that means that in between those intervals all the peripherals are de-activated and the gpio's are latched to their state before the device goes to sleep, for example if the pin was on when the device goes to sleep it will still stay on, but in the next connection / advertising interval the device will wake up and run again the periph_setup function, that means that the gpio will be reconfigured and have the state that is determined in that function.
  • So depending the advertising and connection interval, the device will sleep and wake up automatically (if the pm_set_sleep_mode(pm_extended_sleep)). When you write a characteristic, the device will not wait for 8 seconds to go in that mode (this only happnens when the device boots up), but will immidiatelly sleep when it will find the chance until the next connection / advertising event. So when you set that mode the device will disable all peripherals until its time to wake up again. Regarding that you set the sleep mode and the device immidiatelly disconnect, you will have to check where the code in the device ends up, because i think that it might hit an ASSERT or the device stalls for somereason when you enable sleep. Perhaps due to the external devices consuming to much power when the device falls in sleep mode.
  • Regarding the VBUS as mentioned this is configured automatically if you use the USB definitions, i 've mentioned that in an older post, when the USB is attached or there is a voltage sense on the VBUS then the VBUS_Handler() will be triggered and the device will wake up, and you are able to hook your functionallity in the usb_attach_cb() hook.

Thanks MT_dialog

Myken
Offline
Last seen: 25 min 51 sec ago
Joined: 2016-07-13 20:06
Right!

Right!
The thing I missed was that the device will go into sleep mode BETWEEN advertising intervals. Not as I thought after I stopped advertising altogether.
My external devices DO consume to much power at that point and a ASSERT is very probable.

Regarding the re-initialization of the gpio after wake up you refer to a periph_setup function, there is no periph_setup function.
However there is a static void pm_init_wake_up(void) function, that will “Initialize the system after wake-up”.
In this function there is the following code:

if (periph_init != NULL) {
periph_init(); // Power on peripherals and GPIOs
}

periph_init is a pointer to a function that initialize the gpio. AND this pointer is initialized in the
void pm_system_init(periph_init_cb peripherals_initialization) function.

So in order to automatically initialize the gpio at wake up you must call the function
pm_system_init(name_of_function_that_initialize_the_gpio);
in your main during system initialization.

If I do that there is absolutely no need to use the usb_attach_cb().

If you mean by "periph_setup" function the "name_of_function_that_initialize_the_gpio" function it finally makes sense.

The dk_apps/features/ble_peripheral/ template I use has the following code:
pm_system_init(NULL);
and therefore the re-initialization of gpio will never happen.

May I suggest a better documentation of this feature to give people like me a quicker understanding how it is all connected together.
In all the examples it look like an arbitrary choice to initialize the gpio in that way.

Thanks.

MT_dialog
Offline
Last seen: 23 min 25 sec ago
Staff
Joined: 2015-06-08 11:34
Hi Myken,

Hi Myken,

Yes, regarding the periph_setup(), the function that i am talking about, is the function that should be passed as a parameter in the pm_system_init() as you said, in most BLE examples is called periph_init(), sorry about that, i will make sure to pass your comments to the documentation team.

Thanks MT_dialog