SparkFun Forums 

Where electronics enthusiasts find answers.

Everything with the AmbiqSuite SDK tools and software are welcome here.
User avatar
By robin_hodgson
#211710
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:
Code: Select all
// 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:
Code: Select all
// 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!
 Topic permissions

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum