Not Entering into Sleep Mode

Hi Magesh, 

Thanks for your question on the forums and apologies for the delay. We are currently checking that and will get back to you ASAP. 

Thanks, PM_Dialog

Hi Magesh,

Extended and deep sleep are completely different sleep mode.  When the device is configured in extended sleep, it will go into sleep between advertising or connection interval. In deep sleep mode, the 69x cannot advertise or maintain a connection.

So, if the extended sleep mode is enabled (enable by default - pm_sleep_mode_set(pm_mode_extended_sleep); ) , the chip will sleep between the intervals. If you would like to put it into permanent sleep mode, you should stop advertising.

As mentioned above, they are two different sleep modes. Of course, the current consumption will be much lower in deep sleep mode. Let me try to explain how the device behaves when in deep sleep and what are the conditions to deep sleep successfully :

• The ARM M33 goes to WFI state.

• OS tick period is extended based on the earliest wake-up time.

• The Power Domain Controller allows the system to go to sleep, if possible. This is achieved by checking the pending activity on the rest of the masters (ARM M0+ and Sensor Node Controller).

• If the Power Domain Controller decides that the device can go to sleep, then the HW FSM takes over and moves to “SLEEP” state.

• RAM is not retained, RTC is on (XTAL32K is used as sleep clock), all power domains are off.

• The system could be configured to wake up by RTC alarm or a GPIO trigger.

I would say that deep sleep is a “clocked Hibernation” practically. If it goes successfully to deep sleep, the SW is LOST, the HW is POWERED-OFF except from the WKUP controller and the RTC. There is NO active code, NO other active blocks except from the WKUP controller and RTC blocks. Waking from this mode (same is hibernation mode) is equal to cold-boot, because there is nothing retained.

For that case, there are some conditions that will prevent the DA1469x from going into deep sleep. So, it will NOT go to deep sleep, if:

1. the debugger is attached the CPU (like when attaching the J-LINK debugger and stepping through the code)

2. there are any open adapters.

3. there is any OS even in a very short time which does not leave enough time

4. there are pending FLASH write operations

5. there are active tasks

To go into deep sleep successfully, all of the following conditions should be true :

1. All tasks are RTOS tasks (except the IDLE task) are suspended (not running). All the tasks should be in IDLE state

2. there are NO pending interrupts (put the sensor in sleep/power down mode )

3. there is NO transaction active through the adapters interface

4. there are NO intensive write flash operations

5. the J-LINK debugger is not attached (there is no active debugging session)

To put the device into the desirable sleep mode the pm_sleep_mode_set() should be used.

When trying to stop advertising by using the ble_gap_adv_stop() API, you should get a BLE_EVT_GAP_ADV_COMPLETED message that is handled in for (;;) { } in the application task. So, the handle_evt_gap_adv_completed() callback is triggered when the advertising is finished. In that function, you should not advertise again and put the device into sleep mode. In case the code still halts, I would suggest to run it in debug mode and share more debugging information

Thanks, PM_Dialog

Thanks for the reply,

I have done the procedure for deep sleep mentioned and it enters the sleep mode, but how to wake from deep sleep or hibernation. 

Thanks and regards,

Magesh V 

Hi Mages, 

According to the DA469x datasheet : 

Hibernation mode. This is the “shipping mode”. There is no RAM retained, no clocks running (so no RTC), all domains are off, the system can only be woken up by POR, HW reset or a GPIO trigger. To enter this more, RC32K has to be selected as the low power clock. This is the oscillator started after a GPIO trigger that wakes up the complete system. Note that, when woken up, the system resets.

Deep Sleep mode. No RAM is retained, XTAL32K is running (so RTC is on), all domains are off, the system can only be woken up by POR, RTC alarm or a GPIO trigger.

GPIO trigger means configuring the Wake-up controller and wake up via a GPIO trigger. Please check out this SW example : https://github.com/dialog-semiconductor/BLE_SDK10_examples/tree/main/fe…

Thanks, PM_Dialog

Hi PM Dialog,

I am able put the device in power down and wake from sleep, but the current consumption is not as per the datasheet. I am putting the system into deep sleep and switch off all task and other things, but still it consumes from MIN : 24 mA to MAX: 43 mA. How can i put the flash into sleep or why it is consuming so high in deep sleep?

Regards,

Magesh v

Ηι Magesh, 

Which flash part number are you using? Is it a custom board, or any of our DKs? 

I would recommend checking DA1469x Power Consumption Tutorial , chapter 2.1.7. Flash Powered Down. 

It is strongly advised to set #define dg_configFLASH_POWER_DOWN ( 1 ) in custom_config_qspi.h file of the measured device in order to explicitly state that the flash will also enter low power mode during sleep. The difference can be larger than 5μΑ in average.

Note

Dialog supports three different flash devices for the DA1469x family products that are guaranteed to work.

• Macronix MX25U3235F
• Winbond W25Q32FW
• GigaDevice GD25LE32

However, most of the flash devices are likely to work provided a proper driver exists or is developed for them. There are several low power consumption flash devices (e.g. Macronix MX25R3235F ) that when properly set, they can have an impact on the device’s power consumption. While this is something that could reduce the power consumption, it is up to the reader to successfully install the flash and develop the drivers for it.

A tutorial on how to write a custom Flash Driver for DA1469x is provided by Dialog and can be found here http://lpccs-docs.dialog-semiconductor.com/da1469x_creating_flash_drive…

If you have any follow up questions, please raise a new forum ticket. 

Regards, 

PM_Dialog