For some time now, Segger has been offering Real Time Terminal (RTT) technology for its JTAG JTAG adapters. Its essence is that the program on the microcontroller can output and receive debugging information from the JTAG / SWJ-DP port, as is usually done through the UART. And then we no longer need a real debug UART. Then a little more about the possibilities of this technology.

The ability of the program to output debugging information to the JTAG / SWJ-DP port was implemented as soon as the microcontroller had this port. There are two ways to do this: use the semihosting technique or the Serial Wire Output (SWO) technique.

Using semihosting leads to the substitution of input-output channels for standard file operations of the C language. This is not always acceptable, since the file operations in the application may already be used for another purpose. Also semihosting needs to explicitly disable and recompile the project when releasing the release version.

On top of that, semihosting provides the slowest data transfer from the technologies considered here.
')
Using Serial Wire Output is simpler than semihosting, however, it requires the use of an additional SWO signal from the JTAG / SWJ-DP port, and also necessitates recompilation when switching to the release version, i.e. version without connecting a debugger. SWO output functions are synchronous, i.e. expect port readiness and do not possess the necessary determinism.

Segger's Real Time Terminal technology makes it even easier to display debug information via SWJ-DP and provides the following amenities :
• Only two external lines are enough - this is SW CLK and SW DIO.
• All additional code in the microcontroller takes no more than 500 bytes, if you do not use the input, then even 300 bytes.
• No recompilation is required for the release version, the debug output functions are asynchronous and practically do not take up CPU time and do not have any influence on the program execution in the absence of a debug adapter.
• The debug I / O speed is very high.
• Debug I / O can be redirected to any third-party program terminal emulator supporting the telnet protocol.
• Segger provides free terminal emulator, logger and telnet client utilities for connecting to the microcontroller via a debug adapter without having to run third-party IDE with debuggers.

An example of using RTT.

The figure above shows a controller board based on the STM32F745VET6 chip. The outer quartz is 16 MHz. The core frequency is 168 MHz.
Debugging was required for the bootstrap over the CAN bus. The RS232 serial port connected to the UART is, but also used for the bootloader. To display debugging information in it would mean to modify the debugging version of the program compared to the release version. With a lack of time, this is highly undesirable.

The following steps were performed to connect the RTT:

1. RTT sources are taken ( http://download.segger.com/J-Link/RTT/RTT_Implementation_141217.zip )
2. The sources are unpacked and copied into a project directory called RTT. The project itself was carried out in the environment Keil MDK ARM
3. Sources are connected to the project. The files SEGGER_RTT.h and SEGGER_RTT_Conf.h are added to the general list of project header files.
4. Additional settings were made in the SEGGER_RTT_Conf.h file: the value of BUFFER_SIZE_UP was increased to 2048, the value of SEGGER_RTT_PRINTF_BUFFER_SIZE was increased to 512. The parameters changed in fact iteratively until the overflows of the specified buffers ceased.
5. Editing the source of the bootloader. In all places of interest, calls to the SEGGER_RTT_printf function were inserted with the necessary messages. I used this function as the most convenient, although it introduces a significant stack consumption and a certain data conversion delay. But in my case it was acceptable.
6. Since debugging was needed even while programming the internal Flash, I transferred the RTT code to the microcontroller's RAM. For this, in all 2 source files, RTT introduced the directive
   

   #pragma arm section code = "CODE_IN_RAM",

   
   and in the linker file .sct defined this area as follows:
   

   RW_IRAM1 0x20000000 0x00010000
   {
   .ANY (+ RW + ZI)
   * (CODE_IN_RAM)
   }

7. Determined for the structure SEGGER_RTT_CB absolute address of placement directive
   

   static SEGGER_RTT_CB _SEGGER_RTT __ attribute __ ((at (0x20000000)))

8. Compiled project. After compilation it turned out that the RTT code in RAM took 400 bytes with zero optimization.
9. Pasted JLinkRTTViewer.exe utility into IDE Keil's tool menu.
10. Since I prefer to use TeraTerm as a term emulator, I inserted a call into the menu as well. The call string is as follows:

    "C: / Program Files (x86) /teraterm/ttermpro.exe" / T = 1 telnet: // localhost: 19021 / X = 0 / Y = 0 / W = "J-Link RTT"

Bandwidth

It seemed interesting how fast the information is output to the terminal emulator via a debug adapter using RTT. Oscillograms were taken from SW SLK and SW DIO signals.

It turned out that J-Link uses polling at intervals of about 40 ms. For data transfer no more than 50% of this period is used. In a block of data transmitted over a period, packets carrying useful data also take no more than 50% of the time. Packets carry no more than 3 bytes of payload. Three bytes of useful data in the packet also occupy no more than 50% of its length. Total we get: 0.5 * 0.5 * 0.5 = 0.125, i.e. 12.5% ​​of the bandwidth of the SW channel is used to transfer debug output.

The channel frequency above 4 MHz in J-Link could not be raised at any settings. This means that we have the maximum transfer rate of 4 Mbps. Of these, only 4 * 0.125 = 0.5, i.e. 500 Kbps at best can be used for debugging output. This, of course, is not much compared to the actual debugging UART, which can transmit at speeds of several Mb / s, but everything comes at a price.