[SOLVED] What is the realtime impact of RTT on the target?

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

  • [SOLVED] What is the realtime impact of RTT on the target?

    We recently refactored our little nRF52 project. Removed FreeRTOS from the project and updated to the Nordic's SDK15.

    Since that time however I noticed RTT seems to have a pretty hefty impact on the system's realtime performance (which isn't very good already due to the softdevice running on it). As soon as I enable the RTT viewer (or oZone with RTT terminal enabled), bluetooth crawls down to a full stop. Apparently, RTT destroys the softdevice's timing somehow.

    The system is idle most of the time, CPU utilization is well below 10%. nRF52 at full speed (32 MHz crystal), we're using SWD on a J-Link Plus. We keep the drivers up to date as much as possible, we're now at J-Link 6.32c. I tried reducing SWD speed to as low as 10kHz (I could go 5 kHz, but then RTT crashes) and even at this speed RTT impact is noticeable. It's not that we print a lot of information either: a time and battery value once per second, that's all.

    Thus my question: what is the impact of RTT on the system's realtime performance supposed to be?

  • Hello,

    Thank you for your inquiry.
    The general RTT performance impact is minimal as J-Link periodically grabs the RTT information from MCU memory. In that moment wait states can appear, but in all other cases the MCU has priority and there is no impact at all.
    Are you using any sleep modes or WFIs? Some target devices disable external memory access during sleep modes which could lead to the described behaviour.
    Does removing the sleep/WFI parts from your application improve the behaviour?

    jev wrote:

    I tried reducing SWD speed to as low as 10kHz (I could go 5 kHz, but then RTT crashes) and even at this speed RTT impact is noticeable.
    We recommend using higher speeds than that for an optimal debug experience. J-Link will only access the target if needed for debugging so it does not matter if you select 10 kHz or 10 MHz.
    The interface speed should only be lowered if signal quality is bad.

    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.

  • Thanks for the explanation. Unfortunately, no, I don't use any WFI and disabled power management (no sleep modes therefore).

    It's weird then that reducing SWD speed to low speed or disabling RTT makes things work correctly. I mean, the debugger still operates, even at 4 MHz. I enable RTT and *poof*, dead. Slow SWD down to 10 kHz and the system works again (albeight a bit slow).