This direct H/W debugger access is selected by the SystemView application J-Link Recorder Configuration option.

When using a H/W debugger interface that supports exposing RTT channels via TCP/IP network streams then a proxy helper application can be used to obtain the H/W debugger accessed RTT buffer data for SystemView from the debugger, and present a SystemView application IP Recorder channel to the viewer application.

The host/svproxy.c source implements a simple BSD socket interface Linux example implementation. It provides a connection between the Segger SystemView application IP Recorder support and a non-Segger H/W debugger which presents the data from RTT channel 1 "SystemView" as a network stream (for example Ronetix PEEDI, or OpenOCD).

The proxy provides a service on a specified port allowing the SystemView application to connect and wait for event data to be supplied. The proxy does not need to execute on the same host as the SystemView application.

The target H/W debugger supplied stream should be referenced using its network address and port number as presented by the H/W debugger session. NOTE: The examples below assume that the target H/W debug session has been started, and that the eCos application executed until after the SEGGER_SYSVIEW_Conf() function has completed (to initialise the data structure searched for by the H/W debugger). This can be achieved by setting a breakpoint on the function cyg_hal_invoke_constructors() as a holding place whilst the H/W debugger network server is started and the svproxy tool executed.

For example, assuming a PEEDI configured to expose the RTT channel 1 on port 19112 as follows:

rt1064evk_swd> rtt setup 0x80030000 0x10000
rt1064evk_swd> rtt start
++ info: control block found at 0x8003AD1C
rt1064evk_swd> rtt list
target -> host (max 2):
    0: 'Terminal', size 1024
    1: 'SysView', size 8192
host -> target (max 2):
    0: 'Terminal', size 16
    1: 'SysView', size 8
rt1064evk_swd> rtt server_start 19112 1

Using OpenOCD is very similar, where via the telnet server exposed via OpenOCD or using the GDB monitor command support, a RTT server can be started supplied channel 1 on a network connection. The only difference being that the rtt setup requires the Segger identification string when searching for the memory based descriptor. e.g.

rtt setup 0x24000000 0x40000 “SEGGER RTT”
rtt start
rtt server start 19112 1

When performing analysis of data captured by the SystemView application, where a run-time I/O mechanism is in use, the user needs to be aware that the act of recording measurement events will affect the overall performance of the system. This needs to be taken into account when checking reported performance.

	Note
	The following timing measurements were made against a MIMXRT1064-EVK platform (Cortex-M7 clocked at 432MHz) with a simple GPIO driven signal on J23#1 measured using a Saleae LogicPro16. The GPIO line was set and cleared as the first and last operations respectively of the Cyg_RealTimeClock::isr which is the ISR handler for the SysTick event.

For the following table the SysTick ISR was chosen as an example, since it is a high-frequency, common event that is likely to be used when analysing scheduling and thread interactions. On most systems it is configured with a 10ms period.

In the following table, the acronyms used in the headers are:

As can be seen there is a huge difference in the time taken to execute that single, relatively simple, ISR function depending on the compiler optimisation level, whether or not memory-buffer based Kernel-instrumentation is enabled, or whether the kernel-instrumentation is directed to a SystemView Recorder (the HAL recorder in the example above) where there is the cost of transmitting the bytes over a UART channel (where the configured baud rate of that channel will also affect the timing reported) or is accessed via H/W debugger background memory accesses. The table highlights that any software based instrumentation solution has a hit on the system throughput.

So tuning of the SystemView captures, and the speed of the underlying transport channel need to be considered when performing anaylsis based on how the data was captured for SystemView.