RTT

From SEGGER Wiki
Revision as of 09:46, 25 September 2019 by Leon (talk | contribs)
Jump to: navigation, search

Modes

SEGGER RTT (SEGGER Real Time Transfer) can run in different modes where some modes are not available on all devices but other modes are which then have an impact on the real time behavior of the device.

Background mode

This is the mode which RTT was initially introduced with. In this mode, J-Link can access the memory of the target system while the MCU + application keeps running (background memory access), effectively not impacting the real time behavior of the application. In order to use this mode, the target MCU needs to support background memory accesses.

Cores with background mode support

  • Cortex-M based devices (all cores from the series)
  • Renesas RX based devices (all cores from the series)

Cores with optional background mode support

  • Cortex-A based devices (all cores from the series)
  • Cortex-R based devices (all cores from the series)
  • RISC-V based devices

Cortex-A/R specific

It depends on the actual device if it supports background memory accesses because it is up to the device vendor if the necessary hardware unit is implemented or not. In addition to that, when using the background mode on Cortex-A/R based devices, some considerations need to be taken into account when it comes to caches etc. These are explained in AN08005

RISC-V specific

It depends on the actual device if it supports background memory accesses. RISC-V specifies a so-called system bus access feature that allows the debug probe to access the memory independent from the core, so R/W memory while the core is running. However, this feature is optional and may not be implemented by the device vendor. Please check the datasheet of the device if system bus access is supported.

Stop mode

This mode has been introduced in J-Link software V6.30 in order to also allow using RTT on devices / CPU architectures that do not support background memory accesses. This mode affects the real time behavior of the application but can still be used for most target applications.

In this mode, J-Link temporarily halts the CPU (interrupts the execution of the target application) to access the memory and continues operation automatically after the memory access is done. The actual impact (halted time) on the real time behavior depends on the setup (target interface speed used, target interface used, length of JTAG chain, actual core that is used, ...).

Cores with stop mode support

  • Cortex-A based devices
  • Cortex-R based devices
  • RISC-V based devices

Note: It is recommended to only use this mode with target interface speeds of 25 MHz or higher (J-Link ULTRA+, J-Link PRO) to keep the effect on the real time behavior as small as possible. J-Link model overview

Effect on real time behavior

Typical halted times for memory read accesses in stop mode with J-Link ULTRA+ @ 50 MHz:

Typical halted times for memory read accesses in stop mode with J-Link PLUS @ 15 MHz:

TELNET channel of J-Link software

The J-Link software provides a TELNET channel on port 19021 to allow easy access to RTT data from a separate 3rd party application that may run in parallel to the debug session. The TELNET channel is very simple to use and basically all it requires is to open a local TCP/IP connection to port 19021 and start to receive data.

Sample code - TELNET client

In the following, come sample code is given for writing a TELNET client that connects to the TELNET channel of the J-Link software.

The blocking way

Without any special options, a call to connect() of the host OS socket API is blocking until either a connection is established or a timeout is reached. This is the default way but has the disadvantage that the thread calling connect() is blocked and connect exit itself during the timeout counts down, in case an application close request comes in during the count down.

Complete contents of the SYS_ functions can be retrieved from the source code delivered with the J-Link SDK
void TELNET_Client(void) {
  int t;
  int r;
  SYS_SOCKET_HANDLE hSock;
  char ac[512];

  do {
    r = -1;
    printf("Waiting for connection...\n");
    do {
      hSock = SYS_SOCKET_OpenTCP();
      if (hSock == SYS_SOCKET_INVALID_HANDLE) {     // Failed to open socket? => Something basic in the OS failed. Done...
        goto ErrHandler;
      }
      r = SYS_SOCKET_Connect(hSock, 0x7F000001, 19021); // Connect to 127.0.0.1, port 19021
      if (r == 0) {
        break;
      }
      //
      // We need to close a socket and reopen a new one if a timeout occurs,
      // otherwise the OS sometimes does not recognize that
      // the port became available in between
      //
      SYS_SOCKET_Close(hSock);
    } while (r <= 0);
    //
    // Read from TELNET connection
    //
    do {
      r = SYS_SOCKET_Receive(hSock, ac, sizeof(ac) - 1);
      if (r <= 0) {                                       // 0 == Connection gracefully closed by server. < 0 == Some other error
        break;
      }
      ac[r] = 0;
      printf("%s", ac);
    } while (1);
    SYS_SOCKET_Close(hSock);
  } while (1);
ErrHandler:
}

The non-blocking way

It is possible to configure a socket to be non-blocking, so that a call to connect() immediately returns, allowing the thread to remain responsive. In order to check if a connection has been established successfully, the socket status needs to be checked periodically.

Complete contents of the SYS_ functions can be retrieved from the source code delivered with the J-Link SDK

void TELNET_Client(void) {
  int t;
  int r;
  SYS_SOCKET_HANDLE hSock;
  char ac[512];

  do {
    r = -1;
    printf("Waiting for connection...\n");
    do {
      hSock = SYS_SOCKET_OpenTCP();
      if (hSock == SYS_SOCKET_INVALID_HANDLE) {     // Failed to open socket? => Something basic in the OS failed. Done...
        goto ErrHandler;
      }
      SYS_SOCKET_SetNonBlocking(hSock);             // Make sure that connect() returns immediately
      SYS_SOCKET_Connect(hSock, 0x7F000001, 19021); // Connect to 127.0.0.1, port 19021
      r = SYS_SOCKET_IsWriteable(hSock, 10);        // Returns if socket is ready to send data (connection established)
      if (r > 0) {
        SYS_SOCKET_SetBlocking(hSock);              // Make sure it is blocking again, to calls to recv() and send() block
        break;
      }
      //
      // We need to close a socket and reopen a new one if a timeout occurs,
      // otherwise the OS sometimes does not recognize that
      // the port became available in between
      //
      SYS_SOCKET_Close(hSock);
    } while (r <= 0);
    //
    // Read from TELNET connection
    //
    do {
      r = SYS_SOCKET_Receive(hSock, ac, sizeof(ac) - 1);
      if (r <= 0) {                                       // 0 == Connection gracefully closed by server. < 0 == Some other error
        break;
      }
      ac[r] = 0;
      printf("%s", ac);
    } while (1);
    SYS_SOCKET_Close(hSock);
  } while (1);
ErrHandler:
}

Low-power modes

Many CPU cores support low-power modes to save power while waiting for an event or interrupt. On Cortex-M for example this is achieved by executing the WFI and WFE instructions. Unfortunately, the exact behavior during low-power modes is depending on the actual device (two devices from different vendors incorporating the same Cortex-M core may behave different).

  • Some devices disable the whole debug unit during low-power modes, causing J-Link to lose the connection to the device.
  • Some keep the debug unit enabled but disable the internal flash and RAM, making it effectively impossible for J-Link to perform RTT requests while the target is in a low-power mode

As the target will be idle most of the time, using low-power modes will effectively make the usage of RTT impossible, as the target memory cannot be accessed 99% of the time while the application is running. Halting the target application will make the device to make up and RAM etc. becomes accessible again. This may be seen as effects like "RTT output is only seen each time the target is halted".

Solution: When using RTT, make sure that low-power modes are not used.

Samples

Troubleshooting

If you have trouble getting RTT to work with your setup, please try the following:

  • Make sure the target device supports RTT. For more information, refer to Modes
  • Make sure that the most recent version of the J-Link software package is used (e.g. RTT sourcecode, JLinkARM.dll, J-Link RTT Viewer, J-Link RTT Client, etc.)
  • Make sure the target application uses the correct RTT mode for each buffer (Note: Every mode except for SEGGER_RTT_MODE_BLOCK_IF_FIFO_FULL may lead to loss of RTT data if the target writes RTT data faster than the host fetches it)
  • Make sure the target application does not use low-power modes. For more information, refer to Low power modes
  • Make sure the RTT Control Block is placed in RAM
  • Make sure that there is only one application on host-side that fetches RTT data. When running multiple applications (e.g. J-Link RTT Viewer and J-Link RTT Client) in parallel, one can "steal" data from the other, leading to fragmented RTT logs
  • Make sure that the RTT Control Block can be located by the J-Link DLL:
    • For Auto-Detection to work, J-Link needs to be passed the correct target device name (the target core name alone is NOT sufficient for Auto-detection)
    • The address of the RTT Control block can be set using J-Link command strings.
    • Address ranges for J-Link to look for the RTT Control block can be set using J-Link command strings.