SEGGER RTT - stm32 - erratic output when testing low power modes (WFI)

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • SEGGER RTT - stm32 - erratic output when testing low power modes (WFI)

      Getting some erratic RTT output when I added sleep (WFI) to my stm32f411re design. Basically when I start a debug session, I don't see any RTT output (as the code basically starts up and goes into SLEEP (not stop or standby).. It stays in Sleep until an RTC wake up interrupt occurs. The code has RTT output leading up to this point, but none of it is shown. However if I pause the debugger and resume it'll print out all the outputs that didn't come out to begin with.


      I see some previous forum posts in 2016 regarding stm32 issues with sleep and J-Link not able to read data.

      I have turned on the DBGMCU during sleep mode, so HCLK stays attached to the debugging unit on the MCU.

      Source Code

      1. __STATIC_INLINE void LL_DBGMCU_EnableDBGSleepMode(void)
      2. {
      3. SET_BIT(DBGMCU->CR, DBGMCU_CR_DBG_SLEEP);
      4. }
      are we still in the same boat with regards to being unable to debug stm32's with sleep mode enabled? it would sure be useful.. Do some of the newer stm32L4 parts have the same problems? Or is this in general a problem across all the cortex-M4 variants?


      cheers,
      Paul
    • Hello Paul,

      Thank you for your inquiry.

      pmurdock wrote:

      are we still in the same boat with regards to being unable to debug stm32's with sleep mode enabled? it would sure be useful.. Do some of the newer stm32L4 parts have the same problems? Or is this in general a problem across all the cortex-M4 variants?
      The STM32F411 hardware has not changed in the last two years so the issue will still be there.
      For information about the L4 series we suggest contacting ST if memory access is possible during sleep mode.
      It is however not a generic issue with Cortex-M4, just specific ST devices.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      The following contact form can be used for this: Contact Us

    • so the follow up question is that this should only affect rtt output just prior to sleep no?

      Upon wakeup output should continue as normal no? I put some 10ms delays just prior to and after the WFI to try to give it time to flush out. That should help should it not?

      Cheers
      Paul
    • Hello Paul,

      pmurdock wrote:

      so the follow up question is that this should only affect rtt output just prior to sleep no?
      Correct.

      pmurdock wrote:

      Upon wakeup output should continue as normal no?
      Yes. Including the RTT data still in RAM before the sleep.

      pmurdock wrote:

      I put some 10ms delays just prior to and after the WFI to try to give it time to flush out. That should help should it not?
      It can help, depends on how the J-Link RTT read timing is at that point in the application.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      The following contact form can be used for this: Contact Us

    • Interesting.. I think perhaps what I am facing is that the device wakes up, performs its work (@100MHz) and then promptly goes back to sleep again.. Because of the speed differential between the JLink and CPU it just goes back to sleep to quickly, and thus I just never get any output from the wake-up task because it just happens too quickly.. :(
    • Hello,

      Yes, that is most likely the situation here.
      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.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      The following contact form can be used for this: Contact Us

    • Hello Paul,

      Unfortunately we do not have such a list. We suggest contacting ST in that regard.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      The following contact form can be used for this: Contact Us