How to get Segger RTT to work with sleep modes on stm32

[medanis]

I'm trying to use RTT on an stm32L433 and it looks like it doesn't work when the device is in sleep mode (no output on the RTTViewer).

my test code is a loop with a printf and a 2seconds sleep.

• when a debugger is attached, stepping through the code makes it works fine
• when a debugger is attached running the code yields no output on the RTTViewer
• stopping the code after it runs for a little bit prints all the previously missed outputs
• replacing the sleep with a busy wait loop makes it work correctly
• mixing busy loop and sleep seems to works most time depending on the proportion of active/sleep times

it seems like I'm experiencing the same issue as this thread form the SEGGER Forum,

to summarize the issue from that thread

"The target device goes to sleep again before RTT data can be read by J-Link.

With other target devices this is usually not an issue as the AHB-AP is still active during sleep so J-Link can access RTT data.

This is however not the case for most ST target devices."

I tried setting DBG_SLEEP, DBG_STOP, and DBG_STANDBY to 1 in the DBGMCU_CR register but that didn't change the result.

is there anything else that needs to be done so that a debugger can read the memory while the processor is in sleep mode?

another thread with the same issue

Thanks

[Andrew Neil]

What you need to do is to make sure that there's no RTT data pending before you go to sleep.

Nordic seem to have come up with a way to do this for their nRF52 chips, but I found it to be rather too deeply buried in their own layers of abstraction.

Segger don't seem to directly supply a useful API to tell when RTT data pending - perhaps go back to Segger with that question ... ?

[medanis]

yes that works, I am using that as a work around.

they do provide SEGGER_RTT_GetAvailWriteSpace which could be used to determine if any data is pending, alternatively they provide the source code so it is easy to add a function for that.

but the cortexM4 has an AHB-AP and a debugger should be able to read the memory in the background. there must be a setting somewhere to enable that.

[medanis]

setting DBG_SLEEP, DBG_STOP, and DBG_STANDBY to 1 in the DBGMCU_CR and enabling one of the DMA channels in RCC_AHB1ENR seems to do the trick

[Andrew Neil]

@medanis​ : "the cortexM4 has an AHB-AP and a debugger should be able to read the memory in the background"

Not so sure about that.

As the Segger post says, the choice of what gets turned off in various "sleep" modes is down to the implementer (eg, ST) - it's going to be a tradeoff of lowest-power against debuggability.

Looks like ST have gone in favour of lowest-power here.

Debugging very low-power systems is always a challenge :worried_face:

[Andrew Neil]

Good to know.

What's the impact on current consumption?

[medanis]

according to the datasheet, 1.3uA/MHz

[Andrew Neil]

@medanis​ "they do provide SEGGER_RTT_GetAvailWriteSpace"

That seems to be a fairly recent addition: v6.54; Nov 2019 - so perhaps it hadn't been added at the time I was last looking.

Anyhow, good to know it's now there ...

I guess the check is (SEGGER_RTT_GetAvailWriteSpace() == BUFFER_SIZE_UP) ?

[Andrew Neil]

"perhaps it hadn't been added at the time I was last looking"

That does, indeed, seem to be the case.

I notice there's also a SEGGER_RTT_GetBytesInBuffer() ...

[Andrew Neil]

Follow-up for RTT on STM32L0:

https://community.st.com/s/question/0D53W00001EgPohSAF/how-to-get-segger-rtt-to-work-with-sleep-modes-on-stm32l0-