What is the expected RSL10 boot time coming out of deep sleep I/O wakeup?

I’m seeing more than eight seconds elapse from the time i toggle the wakeup pad on the RSL10 in deep sleep, I/O wakeup mode to the time I am back in main(). This seems very excessive. What should I expect the boot time to be, and what can I monitor to narrow down what might be going on?


Are you facing that boot time in your custom code or are you using one of our sample codes? If you are using one of our sample codes which one? Could you please provide?

Thank you for cooperation and for using our Community Forum.

This is our custom application derived from the peripheral server sleep example application. I definitely have the processor in sleep mode according to current measurements. In my example application I toggle a GPIO at the start of main(). More than eight seconds elapse from the time i toggle the wakeup pin to the time I see the GPIO in main() toggle.

I don’t need you to debug my code, I just want to know what I should expect the wake up time to be, and what kinds of things might be going on to cause this. I know the power rails are up and stable. Since nothing has been powered off the clocks should be stable. What could possibly be going on?

Hi sigsbee,

Assuming wake up from RAM scenario, the normal wake up time should be in the range of few milliseconds.
The 8 second loop sounds like watchdog timeout to me (4 s -> WDT ISR -> 4 s -> WDT reset) so it is possible the application gets stuck somewhere during the wake up. For example waiting for interrupt using WFI instruction but the interrupt is not re-enabled after wake up.

Similarly, based on the example code, the application should return execution in the Main_Loop function and main should be entered only once after device reset.

Best regards,

Thanks very much for the feedback. I think that sounds likely. I appreciate the help.

I’ve spoken too soon. On the RSL10 eval board, the wakeup works as expected. when the wakeup line (TP3) on the eval board gets toggled, I see the ACS_RESET_FLAG in the DIG_RESET_STATUS set as expected. On our product board, running the same code, I see the ACS_RESET_FLAG, the WATCHDOG_RESET_FLAG, and the LOCKUP_FLAG set in the DIG_RESET_STATUS register when the wakeup pin is toggled. The lockup looks like it’s occurring before I even get into the reset handler in startup_rsl10.S. Since I’m running identical code, I’m wondering if we have a problem in our RSL10 schematic. Can anyone there comment? Thank you.

More information: the RSL10 on our product board appears to be running at a faster clock rate than the eval board when it finally gets into the part of the reset handler that toggles the test gpio. Based on the period of the test signal it looks like about twice as fast.

Based on the watchdog flag it looks like the wake-up itself occurs and reaches program code.
Since the code works on EVK, the deep sleep cycle should be set up correctly.

Do you manipulate any DIO pads or external IO interfaces in your wake-up routine?
It is possible you are reading data from external interfaces before DIO pad retention is disabled and your board may produce different result due to schematic change.
Can you try to put


at the start of the wake-up routine (typically function called Wakeup_From_Sleep_Application) and see if there is any change?

the RSL10 on our product board appears to be running at a faster clock rate

Are you referring a specific clock, like SYSCLK frequency?

I’m toggling a GPIO at the start of ResetHandler, before any of my code runs. This has got to be in the ROM, right?

Also yes, I’m using a counter to turn a GPIO on and off, and the pulse widths are different so it would be the CPU clock.

One last piece of information: We need the RSL10 in its deep sleep mode, waking up on the wakeup pad only. So I’m using code derived from the sleep_RAM_retention example which calls Sleep_Mode_Configure() and the Sys_PowerModes_Sleep_WakeupFromFlash().

So it is wakeup from Flash and not wakeup from RAM scenario.

Is the sleep_RAM_retention example working on your board with the same sleep configuration after you adjust for the LED_DIO and RECOVERY_DIO pad numbers?

That example works, however, it is not really very useful because it does not turn the radio on and does not even start the kernel. It does, however, prompt my first question:

I can find nowhere in the documentation anything that describes the behavior of the watchdog when the RSL10 is in sleep mode. If you turn off the RTC in the example, the watchdog definitely does not go off. So, does the ROM somehow disable the clock or turn the watchdog off in sleep mode?

Some background information: I am working on a medical device that uses the RSL10 as the radio link. There is another processor that countrols our device and communicates with the RSL10 over a serial link. The modes in our device require that the RSL10 go into low-power advertising mode and into deep sleep mode waiting on the wakeup pin for an indefinite amount of time. Some time ago I posted ticket WBL-XGPWS-093 and received help in getting the RSL10 to cycle through all the power modes our device needs. I thought I had this handled until I noticed the over-long boot time I’m seeing in this thread post.

I have eval boards for the other processor and the RSL10 wired together EXACTLY they way they are laid out on our device. In the eval board configuration the RSL10 goes into sleep mode, and wakes up immediately. I have verified this by measuring power. The reset registers in the RSL10 definitely do NOT report a watchdog or lockup error. Running the EXACT SAME EXECUTABLE on our board results in the RSL10 reporting lockup and watchdog timer bits in the reset register. My understanding is that when the RSL10 gets to the WFI instruction, when the wakeup pad gets toggled the ROM sends my code through the same execution path that a reset would do. If that is the case, it looks very much to me like there is something going on the the ROM that’s causing the lockup issue.

Since this is a medical device I cannot let this behavior go and must track it down. I’m quite confident that the code is getting into sleep mode properly. I posted this thread thinking that perhaps there might be something in our layout that might be giving the ROM code trouble somewhere. I do not see how my code gets involved in this issue since the RSL10 is waking up from deep sleep and since my eval board setup is working properly. Are there places in the ROM that can lock up like this?


It seems like you are looking for the exact functionality that has been implemented in our new peripheral_server_sleep_ext sample application.

This sample will first setup the BLE environment and send out a configurable number of advertisements in a burst, going to BLE Sleep between each advertisement. Once the configurable number of advertisements has been sent, the device will save the BLE Stack information into RAM, setup the retention, and then enter a Deep Sleep mode. The device will continuously Sleep until a transition is detected on DIO0, at which point it will wakeup and advertise another burst. If the device becomes Connected during one of the burst, it will no longer go into Deep Sleep, but will still enter BLE Sleep in-between Connection Intervals. If the device is then Disconnected, it will again send out a burst of Advertisements before returning to Deep Sleep mode, until another DIO transition is detected.

Please try to evaluate the peripheral_server_sleep_ext sample application to see if its functionality satisfies your requirements.

Thank you for using our Community Forum.

First, please answer the watchdog question: somehow the watchdog is getting disabled in sleep mode, right?

Second - I’m aware of this example. I will review this yet again and will get back to you.

This is more than a little irritating. After running the radio with a short advertising interval, then a long one, and if not one connects I want the processor to turn completely off in the 25 nA deep sleep mode until I toggle wakeup. The documentation implies that the sleep_RAM_retention example does this. Are these two examples incompatible?


To answer the first question, yes the Watchdog timer is disabled during Standby and Sleep operations. Users do not need to worry about this timeout while in one of these operating modes.

Second, it is important to understand that there are 2 Sleep modes on RSL10.

A Deep Sleep mode and a BLE Sleep Mode.

BLE Sleep Mode uses the BB Timer to Sleep in-between Advertisements and Connection Intervals and will retain the BB settings during sleep (to enable fast BLE operations after wake-up),


Deep Sleep by default will shut-down the entire BLE and BB hardware.

Our ‘sleep_RAM_retention’ sample will only show how the Deep Sleep functionality works. To get BLE working with this type of sleep, it requires the BB to be properly shut-down before Deep Sleep is activated (likely why you seeing a crash). Also, if you do not retain the BB settings while sleeping, it will take a long time to reconfigure the BB after waking from Deep Sleep (~500ms). This sample will achieve ~40nA in Deep Sleep mode.

This is why we are recommending the ‘peripheral_server_sleep_ext’ sample as a starting point.

This sample shows how the user can use both Deep Sleep and BLE Sleep together in an application. It will use BLE Sleep in-between the Advertisements and Connection Intervals to lower the average consumption (otherwise, active-mode will be between these intervals, greatly increasing power consumption), as well as using Deep Sleep in-between the Advertising bursts (while retaining the BB settings so the ~500ms setup time is not incurred [it can advertise immediately on wake-up]).

This sample will demonstrate ~110nA Deep Sleep current (higher consumption to retain the BB memory) and ~160nA BLE Sleep.

If you prefer to maintain the ~40nA during Deep Sleep, and do not mind the longer ~500ms BLE delay on wake-up, you can disable the RAM Retention. In this case, the same logical flow used in ‘peripheral_server_sleep_ext’ should be used to ensure that the BB is properly shut down before entering Deep Sleep mode. As mentioned before, shutting down the BB and BLE operation properly before entering Deep Sleep is important to avoid Hardfaults and Sleep mode lock-ups.