J-Link RTT Viewer requires Disconnect / Reconnect

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

    • J-Link RTT Viewer requires Disconnect / Reconnect

      Hello,
      I have a problem, porting an nRF5340 based Zephyr project from logging to an UART to logging via RTT. I have a J-Trace Pro Cortex-A/R/M connected to a Nordic nRF53. JLink Software Version 7.96c. Maybe someone here has made similar experiences and has an idea as to how to overcome them.

      Observation: Zephyr is configured to use RTT as logging backend. I have small test program, that just writes some log messages. Logging to JLinkRTTViewer stops as soon, as I reset the device. Once, I disconnect and connect again, messages are visible again.

      Is this expected behavior? My Nordic-flavor of Zephyr uses this version of RTT: github.com/zephyrproject-rtos/segger

      best regards

      Torsten

    • Hi Torsten,
      this depends on how you reset the device and what exactly happens when you do so.

      From the description I would guess that the debug interface is reset,
      so a reconnect is required to establish it again.
      As an active debug interface is a mandatory requirement for RTT to work,
      it would explain the observed behavior.

      BR
      Fabian
      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 Fabian,
      I reset the device in two situations:
      - While flashing new firmware, where the reset is then executed by the JTrace
      - By simply performing a hardware reset (pull nReset to low)

      In both cases, I have to do the reconnect, which is somehow annoying. I do not power down the JTrace, nor do I disconnect the JTrace. To me, this doesn't look like uncommon use cases ;)

      Do you think, this could be improved somehow?

      best regards

      Torsten

      Other observation: When I do some logging with a frequency of 1Hz, I see that log line with a frequency of 0.5Hz being displayed in JLinkRTTViewer

    • Not sure if you understood Fabian’s post…
      “Sinply pulling nReset” is something that can disturb a debug (and so RTT) session.
      Pulling the reset pin may also reset the debug interface and cause a connection loss.
      Even if it does not, it may cause memory access errors or garbage being read from the buffers (e.g. the startup code re-initializes the control block to 0 while J-Trace is currently evaluating the buffer positions). Such error cases may lead to an RTT “safety shutdown” where the buffer is considered as being corrupted and so RTT handling stops.
      So just because it does not seem to be uncommon does not mean that it will work…
      Using low power modes (e.g. the WFI instruction on Cortex-M) is common for all RTOSes but can easily disturb debugging on many devices, so it is usually encapsulated to be not compiled into debug builds.

      There is no guarantee that RTT will work beyond a reset.
      If it does: Fine.
      If not: It is what it is.


      BR
      Alex
      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 Alex,
      well I'm not sure, if I really want to understand the inner details of your RTT implementation. According to the white paper on your website, it is basically polling some memory regions via SWD. So from technical perspective, I can not see, why the viewer / JTrace stops polling when there was an error condition, but of cause I'm not familiar with all the necessary details.

      Anyway, my task was to replace a debug UART by RTT, which seems to be not possible, because we would always miss the most important part of the logging, namely the startup.

      Thank you both for your time and the insights into RTT.

      best regards und schönes Wochenende

      Torsten