Difference between revisions of "General information about RTT"

From SEGGER Wiki
Jump to: navigation, search
(Background mode)
(Redirected page to RTT)
 
Line 1: Line 1:
  +
#REDIRECT [[RTT]]
__TOC__
 
 
= Modes =
 
SEGGER RTT ([https://www.segger.com/products/debug-probes/j-link/technology/real-time-transfer/about-real-time-transfer/ 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 [https://www.segger.com/downloads/application-notes/ 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. [https://www.segger.com/products/debug-probes/j-link/models/model-overview/ 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''':
 
<gallery>
 
File:Wiki-RTT_StopMode_JTAG_50MHz_256B.png|JTAG @ 50 MHz<br>256 bytes, ~552us
 
File:Wiki-RTT_StopMode_JTAG_50MHz_1B.png|JTAG @ 50 MHz<br>4 bytes, ~418us
 
</gallery>
 
 
Typical halted times for memory read accesses in stop mode with '''J-Link PLUS @ 15 MHz''':
 
<gallery>
 
File:Wiki-RTT_StopMode_JTAG_15MHz_256B.png|JTAG @ 15 MHz<br>256 bytes, ~1.02ms
 
File:Wiki-RTT_StopMode_JTAG_15MHz_1B.png|JTAG @ 15 MHz<br>4 bytes, ~718us
 
</gallery>
 
 
= 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 [https://shop.segger.com/J_Link_SDK_p/8.08.06.htm 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 [https://shop.segger.com/J_Link_SDK_p/8.08.06.htm 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'''.
 

Latest revision as of 08:39, 19 July 2019

Redirect to: