Skip to main content
medanis
medanis
Associate
September 14, 2021
Question

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

  • September 14, 2021
  • 4 replies
  • 3909 views

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

This topic has been closed for replies.

4 replies

Andrew Neil
Andrew Neil
Super User
September 14, 2021

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 ... ?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
medanis
medanisAuthor
Associate
September 15, 2021

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.

Andrew Neil
Andrew Neil
Super User
September 15, 2021

@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:

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
medanis
medanisAuthor
Associate
September 15, 2021

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
Andrew Neil
Super User
September 15, 2021

Good to know.

What's the impact on current consumption?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
medanis
medanisAuthor
Associate
September 15, 2021
according to the datasheet, 1.3uA/MHz
Andrew Neil
Andrew Neil
Super User
December 2, 2021

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-

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Terms & ConditionsAccessibility statement