Can NRF51 wakeup by SEGGER_RTT_VPRINTF()?

[dawei]

Hi,

I am new starter in Nordic platform. I am using device nRF51822-CFAC, the SoftDevice is S130_nRF51_2.0.1(Id: 0x0087).

What I am doing is to put NRF51 into system on sleep mode and waked up by BLE events. I am using sd_app_evt_wait() to put system into sleep mode. My system is pretty simple, no RTC, Push Button, etc. But there do have a SPI connection and a timer. But before system enters sleep mode, I disable the SPI communication and shut the timer.

My code is:

---

if("system is ready to sleep")
{
    "stop SPI communication"
    "stop timer"
    while(1)
    {
        TRACE("try to sleep\n"); //This TRACE function will call NRF_LOG_PRINTF() which is defined as log_rtt_printf() and this log function will call SEGGER_RTT_vprintf() to output debug information.
        sd_app_evt_wait();
    }
}

I am using this TRACE function to see NRF51 goes to sleep mode and stop sending output debug information. The debug information I captured from J-Link RTT Viewer is:

"try to sleep

---

try to sleep

---

try to sleep

---

try to sleeptry to sleep

---

try to sleep

---

try to sleep

---

try to sleep

---

...

---

try to sleeptry to sleep

---

try to sleep

---

..." The bold lines seems show the system enters sleep mode but quickly waked up by something. So my question is: function SEGGER_RTT_VPRINTF() can wake up the system? Please advice.

If I need to remove this TRACE function, is there any flags or API function I can use to check the system is clear to sleep or waked up by what events?

Thanks!

[Hung Bui]

Hi Dawei,

Is the line break also missing when the bold line was printed ? Looks pretty strange.

The CPU is woken up when there is any event. From the softdevice, the source of interrupt/event may come from:

• Connection event (timer)

• Calibration event of the 32kHz RC.

Do you use the 32kHz RC ?

Do you have any other peripheral running that can cause an interrupt, here is the note from the sd_app_evt_wait() documentation:

 * @note If an application interrupt has happened since the last time sd_app_evt_wait was
 *       called this function will return immediately and not go to sleep. This is to avoid race
 *       conditions that can occur when a flag is updated in the interrupt handler and processed
 *       in the main loop.

And

The application must ensure that the pended flag is cleared using 
 * ::sd_nvic_ClearPendingIRQ in order to sleep using this function.

Instead of printing text, you can try to toggle a GPIO pin and then log the toggling using a logic analyzer. If we are lucky, we can see the pattern and figure out what caused the CPU to wake up.

You can also test by not advertising, so the softdevice won't wake up on connection event, it will be easier to spot if smth wrong.