If your systems’ real-time behavior would be noticeably affected by the tracing when using J-Link RTT streaming, this is most likely caused by insufficient throughput, causing the J-Link RTT transfer to block execution. If it works good in snapshot mode, the streaming mode should normally be even faster, otherwise there is blocking in the streaming channel.

The blocking is controlled by a setting in trcStreamingPort.h, TRC_CFG_RTT_MODE, that previously (v3.3 and earlier) was set to blocking mode by default. We now recommend to use SEGGER_RTT_MODE_NO_BLOCK_SKIP instead, in order to avoid “hidden” RTT blocking. This way, if the RTT buffer gets full, you will get dropped events instead of blocking, but the dropped events are then at least visible in Tracealyzer. There is a “Dropped events” counter in the receiving dialog and red fields will be shown in the trace view.

Then you know that the throughput is insufficient. If so, you can improve the streaming performance in several ways:

Avoid J-Link driver issues

Update your J-Link drivers to use the latest version. This also ensures that Tracealyzer uses the same J-Link driver as your IDE.

Note. In december 2017 we discovered an issue in recent J-Link drivers (around v6.22 – v6.30), that may cause performance problems if the debug interface is not set explicitly in Tracealyzer. To avoid this issue, check File -> Settings -> J-Link Settings -> Debug Interface. If this setting is “Default (don’t change)”, change it to SWD or JTAG instead (matching the corresponding setting in your IDE). Many thanks to Erich Styger who first noted this. See also Erich’s blog post on this issue.

Larger RTT buffer

If you have some more RAM to spare, increase the trace buffer size (TRC_CFG_RTT_BUFFER_SIZE_UP in trcStreamingPort.h).

J-Link Interface Speed

In File -> Settings -> J-Link Settings, check the J-Link speed setting. Default is 4 MHz, but can be increased a lot depending on your J-Link model. The “J-Link Base” support up to 15 MHz, and high-end models up to 50 MHz. However, according to SEGGER there is a small risk of getting poor signal quality (i.e., problems) if going above 6 MHz, depending on the development board. But don’t worry, nothing will break and any corrupted data will result in obvious error messages when processing the trace. And if you set the J-Link Speed higher than the maximum supported speed, the J-Link driver will instead use the highest speed supported.

Limit the scope of the tracing

Reduce the amount of data produced, e.g., by excluding frequent User Events or filtering out events using vTraceSetFilterMask + vTraceSetFilterGroup.

Get a faster probe

If nothing else helps, consider upgrading to a faster J-Link probe. Note that the onboard J-Link interface, found on many development boards, ar much slower than a stand-alone J-Link. Even a J-Link Base is several times faster, and a high-end J-Link is even faster.