Power management and RTTLogger

[tautologyclub]

I have played around with _sys_soc_supend and related hooks today, mainly from the nRF52 power mgr example. We verified that it works on a PCB connected to a power consumption tool - we could see the numbers changing when we toggled the GPIOs etc.

But it's completely freaking out when I run it at home (with only the JLink/RTTLogger/GDB available for debugging). Breakpointing _sys_soc_suspend, I notice that it's never called with a tick count high enough to trigger the low power states. It seems some RTTLogger related thread won't let the system sleep.

This should be reproducible on any nRF52 board that can run the power_mgr sample, if we add

CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_HAS_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

to prj.conf.

I'm not sure this can be squarely placed in the category of "bug", but it surely feels a bit Heisenbergian when your RTT-observer severely affects the behavior of what's being observed.

[tautologyclub]

Note: Looks like it can be controlled by setting CONFIG_LOG_PROCESS_THREAD_SLEEP_MS to something larger than default. Works ok.

[carlescufi]

@tautologyclub 2 things to note here: if you have a debugger connected using RTT then the Segger IC will scan the memory continuously to see if there is output to be read, so I am not sure how that impacts power consumption (if it does). Second, you seem to have found a solution that works for you? If that's the case please close the issue with a comment, thanks!

[tautologyclub]

I think it feels a bit bothersome that the logging API is more or less incompatible with the power management API, but I guess if no one uses logging for production code then it doesn't matter much. Closing.

[nordic-krch]

@tautologyclub note that RTT activity requires debug session and permanent high frequency clock.

[tautologyclub]

@nordic-krch This seems to be independent of RTT or not, as long as you have logging enabled and don't explicitly configure LOGGING_THREAD=n or increase LOG_PROCESS_THREAD_SLEEP_MS to something huge. It's not obvious at all that enabling the logging subsystem will start a separate thread that wakes up the CPU several times per second. I think when people enable logging, they're expecting a less hacky printk, not a daemon keeping the system awake.