I recently discovered that when the Apollo3 goes into Deep Sleep, it stops the Segger SWO/RTT communications. What this looks like is situations where your program prints some debug output using the SWO/RTT mechanism and the output gets delayed until the next time the processor comes out of sleep. For tickless RTOS systems, this can be a really long time.
I have found a fix. Part 1 of the fix is that the Apollo3 is a Cortex M4, which means that its software is capable of detecting if a debugger is attached:
// See if a debugger is attached
uint32_t dhcsr = CoreDebug->DHCSR;
bool debuggerAttached = dhcsr & CoreDebug_DHCSR_C_DEBUGEN_Msk;
Second, in my routine that puts the system to sleep, I always let the system sleep if there is no debugger. If there is a debugger, I only let the system sleep if there is no outbound data in the upbuffer:
// If a debugger is present, we only sleep when all outgoing RTT data is sent
if (!debuggerAttached || !SEGGER_RTT_HasDataUp(0)) {
am_hal_sysctrl_sleep(AM_HAL_SYSCTRL_SLEEP_DEEP);
}
Once the RTT application on the far side of the debugger has sucked out all the output, the system will finally be allowed to go to sleep. This has been tested and works great for my purposes.
I am wondering if the ability for software to detect a debugger might be useful for other reasons. Who knows!