Pre defined Default pin state on wake-up from Deep Sleep

Hi rajucoolsuraj,

Could you please clarify and provide me more inputs for what you want to accomplish? If I understood correctly, you would like to go into sleep and as soon as the device wakes-up, the pin should be set to high> Or you want to keep the high pin state while the chip is in sleep mode?

Thanks, PM_Dialog

Hi rajucoolsuraj,

The state of the pin before going to sleep, is retained but not the configuration or the functionality of the pin. when the device wake's up the periph_init() function is called in order to re-configure the pins in each wakeup and the pins return their default application state. So, if any of the GPIOs is high before going to sleep, it will stay high during sleep, and will be reconfigured in wake up by the periph_init() function.

Thanks, PM_Dialog

Hi rajucoolsuraj,

You mentioned the deep sleep mode, so let me aske you something in order to understand you requirement. Have you burnt the OTP?

Thanks, PM_Dialog

Hi rajucoolsuraj,

Normally, when the device is in deep sleep mode the OTP should be burn. However, by defining the CFG_DEVELOPMENT_DEBUG macro da1458x_config_basic.h, you could emulate the deep sleep mode and the OTP mirroring to System RAM. Again, the state of the pin before going to sleep, is retained but not the configuration or the functionality of the pin.

Thanks, PM_Dialog

Hi rajucoolsuraj,

Could you please clarify your question? What do you mean with “resume code execution while deep sleep mode is enabled”?

The DA14585/6 has 3 sleep modes available:

• EXTENDED sleep without OTP copy

• DA14585/6: Only the SystemRAM corresponding of the image size stays switched on

• EXTENDED sleep with OTP copy: There is OTP copy (if boot from OTP).

• DA14585/6: Only 32kB of the SystemRAM remains switched on. The OTP must be burnt to be able to measure the DEEP sleep current.

• DEEP sleep mode: There is OTP copy (if boot from OTP)

• DA14585/6: Only the wakeup controller or the POR circuit remains switched on depending on the option selected.
• This mode can be used for the shipping or hibernation mode. A BLE connection cannot be maintained.

However, by defining the CFG_DEVELOPMENT_DEBUG macro da1458x_config_basic.h, you could emulate the deep sleep mode and the OTP mirroring to System RAM.

In the EXTENDED sleep modes, theDA14585/6 can be woken up in 2 ways

• Synchronously, via the BLE timer which can be programmed to wakeup the system,
• Asynchronously, via an external interrupt (input).

When the DEEP sleep mode is selected, theDA14585/6 can be woken up in 1way:

• Asynchronously, via an external interrupt(input) either from the Power-On-Reset (POR) circuit of from the wake up controller

Thanks, PM_Dialog

Hi rajucoolsuraj,

You could store you data into the Retention-RAM in order to retain them when going to sleep. Please check theSW Example: DA14585/586 Detect the Source of the Resetexample which demonstrates how you could do that. Regarding your last question, you don’t need any other extra configurations.

Thanks, PM_Dialog

Hi rajucoolsuraj,

As it is mentioned in a previous comment, the device retains the state of the pin before going to sleep, but not the configuration or the functionality of the pin. When the device wakes up, the periph_init() function is executed in order to re-configure the pins in each wakeup and the pins return their default application state. When going to sleep, if the GPIO is high, it will stay high during sleep, and will be reconfigured in wake up by the periph_init() function. You will have to be aware in your application the last state of your pins in order to re-apply that value upon wake up.

Thanks, PM_Dialog

Hi rajucoolsuraj,

As far as I understand, you would like to keep the GPIO state when going to sleep, don’t you?

Thanks, PM_Dialog

Hi rajucoolsuraj,

As I mentioned, the state of the pin before going to sleep is retained. So, if I understood correctly, you would like to retain the state of the pin after a SW reset?

Thanks, PM_Dialog

Hi rajucoolsuraj,

Can you please indicate from where the device boots up? From the System-RAM ore from SPI Flash? If it boots from System-RAM, after the reset, the firmware will be lost so you have to download it again, A possible solution is to store the state of the pin into the un-initialized area of the Retention-RAM, and pass this value in the periph_int when configuring the GPIO.

Thanks, PM_Dialog