This timer cannot be disabled while the BLE hardware is initialized due to time keeping purposes.
The BLE needs to wake up to update its internal time reference as we are limited by 32-bit hardware counter in deep sleep.
I typically use this as a watchdog during deep sleep so I can make sure that device wakes up if expected external wake-up does not occur.
From your description you do not seem to need the long term time keeping or RTC so the wake-ups can be disabled during your sleep phase.
Assuming this you can enter deep sleep with external DIO wake-up configuration with no RAM retention and no low power oscillators while waiting for your wake-up signal.
The diagram below shows the application cycle with this approach:
Can you specify at which part does the program stop working?
One problem I had initially was that I did not ensure that DIO Pad Retention is disabled in my regular initialization code in Device_Initialize.
This caused failure after RSL10 woke up, cause DIO were not accessible after sleep when execution started from Flash as normal.
I configure like you said in this thread on the post I cite you. What I can see is that when I disable the FLASH boot and xtal with the configuration of wakeup_ctrl it never wakeups.
My theory about this is that I need the flash memory because I am doing an application with peripheral_server_sleep_ext which I understood that needs to save some configurations from BLE stack to not loose the connection parameters (it is that correct? I am not very sure about it).
Also I have a doubt: I saw that you use sleep_mode_flash_env_tag struct for the configuration of the sleep mode. In peripheral_server_sleep_ext I saw that it is used sleep_mode_init_env struct and also the sleep_mode_env->wakeup_ctrl struct. Which are they differences? Which I should use if I need that system only wakes up by DIO0 rise pulse and I need to maintain it into sleep mode by large amounts of time (minimmum 15 min)
If you use the listed code as is then that pretty much shuts down the RSL10.
I use it for power down mode (transport) and the only way to wake up is reset by toggling NRESET, which is fine for me as I have reset button available.
If you want to be able to wake up you need to modify the power_down_sleep_env.wakeup_ctrl to enable wake-up on one of the 4 DIO pads and also configure the DIO pad as DIO_MODE_INPUT before entering sleep. Or use the WAKEUP pad directly.
If you need to wake-up at specified time then you need to modify to keep the XTAL32K and RTC running and enable RTC Alarm. I did not try flash sleep with this configuration yet.
That said the Flash wake-up is pretty much reset that retains the state of DIO pads.
So no data or BLE configuration is retained.
Ideally only the knowledge of the reset source (DIG status, ACS wakeup status) should be all you need to know to resume your application as nothing else is available.
The structures and Sys_PowerModes_Sleep_* functions represent two specific use cases of sleep mode, so they contain only parameters relevant to them.
Flash mode does not use the init structure or function cause it assumes you need to restart BLE after wake up so no backup of BLE registers is made.
I see what you say. Then I would like to ask you how could I configure sleep_mode_init to maintain BLE Stack active (to not loose my BLE configurations) but also disable the RTC Alarm to make disable the periodic wakeups my Peripheral Device is doing.
Could you give some advice about it?
I think both approaches are equally usable for your purposes.
The main deciding factors I see are power consumption and latency after wake-up.
Flash sleep - lower power consumption since no RAM is retained, longer wake-up time
peripheral_server_sleep_ext approach - larger power consumption due to RAM retention, faster wake-up time
I think exactly this is done in the peripheral_server_sleep_ext example.
RTC is configured separately from BLE (they just use the same clock while in deep sleep) and RTC Alarm is disabled in the example code.
The reason to see only 1 packet after power on is that there is a central client which connects instantly with peripheral server. So it pass directly to the connected state.
Also, I made an if condition to eliminate the advertising after a disconnection is done to try to achieve in the minimum time the deep sleep mode. This is why you only see a single interval before the connection begin.
My issue is with the spikes I have in 35 secs and 93 secs where should be in deep sleep mode and not consumming ~1.5mA. It is very important for my ultra low power requirements.