[ABANDONED] RTT (Real Time Terminal) issues with some (but not all) STM32 MCUs

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

  • [ABANDONED] RTT (Real Time Terminal) issues with some (but not all) STM32 MCUs

    Hi. I'm using RTT inside some sample mbedOS firmwares I wrote in order to get used with that platform.

    While everything works great when I use a STM32F407VG (the MCU on STM32F4-DISCOVERY dev board), I have several issues when running same sample (after having changed target-related settings, of course) on F411RE, 103RB, 401RE and others I tried. Issues vary from having RTT viewer (both stand-alone win32 RTTviewer and ozone integrated terminal) being updated with "bursts" (i.e. anytime a kind-of buffer seems full, e.g. after 256 chars) to not being updated at all.

    I tried changing parameters related to buffers (both down and up) configuration, but without success.

    Any suggestion?

    Thanks!
  • Hello Lorenzo,

    Thank you for your inquiry.

    Does your application use any low power modes?
    When switching from one device to another, did you create a new clean project and added the working RTT files there, or did you simply modify the already working example?
    What IDE are you using for code generation?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino.

    No, my sample app doesn't use any lowpower feature besides what mbedos rtos (that is based on keil rtx) does in its idle task.

    I'm using mbed-cli command line tool in order to drive standard arm_gcc toolchain.

    I also tried to clean intermediate files between compilation for two different targets, but without success.

    You can take a look at code here: github.com/maiorfi/mbedos_lablet_rtos_1

    Thanks!
  • Hello Lorenzo,

    Here is e example project you can use for reference that is outputting printf information over RTT on a STM32F411RE Nucleo board: download.segger.com/Nino/STM32F411RE_RTT_Example.zip
    The Link is available for at least 24 h.

    To debug it you can download and use our IDE Embedded Studio for free for evaluation purposes: segger.com/products/development-tools/embedded-studio/

    The project was created using the Package Manager with the CPU support packages which creates Projects for thousands of devices that run out-of-the-box.

    Could you verify its functionality on your STM32F411RE board?
    If it works, simply compare the source files between the projects.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi.

    I tried your sample and it works without hiccups, despite for my specific issue (more info coming) such sample could not be so explanatory (no delay between printf and main program terminating just after having run all printf statements).

    Indeed, my issue is actually related to RTT fw not flushing to terminal after any printf. I mean that pausing Ozone I can see all printf text output in a single big burst.

    How RTT routines manage output (i.e. toward terminal) buffer flushing, actually?

    Thanks! :)
  • Hi Lorenzo,


    How RTT routines manage output (i.e. toward terminal) buffer flushing, actually?


    RTT gets read as fast as possible (when J-Link is not busy).
    The burst ready you are describing are most likely related to low-power/sleepmode/wait for interrupt functions.
    In that states J-Link cannot acces the target memory and thus cannot read RTT data. The moment the "sleepmode" is off again and J-Link can read the data again you get the data in a burst.
    Check your application for any kind of such mode. You wrote earlier, that your RTOS has a idle mode, make sure there are no modes triggered here that might interfere with the debug interface.

    Does it matter when you halt the application?
    Do you always get the data in a burst after a halt?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Whenever I pause execution (I'm using latest Ozone) I can see all messages queued flushed on terminal.

    Also, if I set a breakpoint on RTT_Printf line and press F10 (step execute) I can see corresponding line being correctly printed on terminal.

    Same firmware built for a STM32F407VG instead of STM32F411RE runs correctly.

    Maybe I should modify SEGGER_RTT_MAX_INTERRUPT_PRIORITY constant?


    By the way, I noted that RTT sample you attached used an older RTT implementation version (5.12 e) than one I'm using (6.20g).
  • Hallo Lorenzo,

    Whenever I pause execution (I'm using latest Ozone) I can see all messages queued flushed on terminal.

    Also, if I set a breakpoint on RTT_Printf line and press F10 (step execute) I can see corresponding line being correctly printed on terminal.


    The reason for it working after a halt or breakpoint is that J-Link sets the target device in a state that the J-Link can get data from it.
    When you press start again the old state gets restored.
    Your application is doing *something* that during execution J-Link can't read from the RTT memory buffer.

    Same firmware built for a STM32F407VG instead of STM32F411RE runs correctly.


    That might be depending on how the chips handle memory differently.

    Maybe I should modify SEGGER_RTT_MAX_INTERRUPT_PRIORITY constant?


    This will most likely not work as the issue is related to not accessible memory and not interrupt priority.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.