[ABANDONED] RTT and SWO questions

  • [ABANDONED] RTT and SWO questions

    I recently started working with RTT and with the GDB servers SWO output functionality, and I have a few questions.

    1. What data transfer rate can I expect using RTT and different interfaces (JTAG, SWD)? On my target (Cortex-M4, 96 MHz CPU clock), RTT transfer rate seems to top out at about 80 kb/s when using SWD, regardless of whether the SWD clock is 10 MHz or 25 MHz. With JTAG, the transfer rate can be as high as 300 kb/s at 25 MHz JTAG clock before data loss occurs. Is it normal that throughput does not increase linearly with JTAG/SWD clock?
    2. I noticed a dramatic increase in RTT TCP/IP throughput after upgrading the J-Link software from 5.00 to the latest version. With the earlier version, TCP/IP throughput appeared to be limited to about 160 kb/s, whereas with the latest software, only the RTT transfer rate seems to be the limiting factor. Are there any settings that influence the transfer speed over the TCP/IP interface?
    3. Are there any easy ways to figure out whether RTT is losing data, or is it necessary to derive this from the data stream itself (e.g. use a data format that contains frame numbers, checksums, etc)?
    4. Is there a way to access the SWO data, possibly in raw form, and without having to use GDB and the GDB server? In most of my debugging scenarious, having a unidirectional link from the target system to the PC that can transfer about 800 kb/s of data would be very useful. I usually do not need to send any data from the PC to the target system, and the data sent from the target is all binary, so I do not need a terminal display.

      I had to install MinGW to activate the SWO output in the GDB server, and the data stream provided by the GDB servers swoport and telnetport appears not to include information like ITM stimulus port numbers, which are contained in the raw SWO data stream.

  • Hello,

    Thank you for your inquiry.
    1: See "Transfer Speed" segger.com/products/debug-prob…about-real-time-transfer/

    2: Could you elaborate what you mean by RTT TCP/IP?

    3: RTT was programmed with maximum performace in mind, so no automatic overflow detection implemented. You could implement int by validating the SEGGER_RTT_Write() return value. Depending on what you want to achieve you can also switch the operating mode. More information can be found in the J-Link user guide in section "Channel buffer configuration".

    4: The J-Link SDK can be used for your own application to gather RAW SWO data: segger.com/products/debug-prob…nk/technology/j-link-sdk/

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • SEGGER - Nino wrote:

    Hello,

    Thank you for your inquiry.
    1: See "Transfer Speed" segger.com/products/debug-prob…about-real-time-transfer/

    2: Could you elaborate what you mean by RTT TCP/IP?

    3: RTT was programmed with maximum performace in mind, so no automatic overflow detection implemented. You could implement int by validating the SEGGER_RTT_Write() return value. Depending on what you want to achieve you can also switch the operating mode. More information can be found in the J-Link user guide in section "Channel buffer configuration".

    4: The J-Link SDK can be used for your own application to gather RAW SWO data: segger.com/products/debug-prob…nk/technology/j-link-sdk/

    Best regards,
    Nino

    Thank you for your speedy reply.

    1. I am asking about experiences with transfer speeds since I cannot seem to reach the transfer rates given in the diagram. When sending 1024-byte blocks every 1ms from my target, RTT achieves a throughput of 302 kb/s according to the control panel with 25 MHz JTAG clock, 290 kb/s with 10 MHz JTAG clock, 189 kb/s with 5556 kHz JTAG clock, and 80 kb/s with 2 MHz JTAG clock.
      The rates appear to stay significantly below the 700 kB/s shown in the diagram. I am using a buffer size of 32768 bytes in my example application.
      With SWD instead of JTAG, the transfer speeds are 72 kB/s@25 MHz SWD clock, still 72 kB/s@10MHz SWD clock, 64 kB/s@5556kHz SWD clock, and 42 kB/s@2MHz SWD clock.
    2. I mean the rate at which RTT data can be read from localhost:19021 by another application. With software version 5.00, this rate appeared to be limited to about 160 kB/s even when the RTT transfer rate shown in the control panel was higher. With the latest software package, higher transfer rates are possible. I assume this is due to the various optimizations mentioned in the release notes of version 5.02.
      Some of the data loss issues I experienced before updating the software package appeared to be due to a bottleneck when sending RTT data out over TCP/IP, not due to the RTT driver not transferring data from the target system quickly enough.
    3. Yes, checking the return value of SEGGER_RTT_Write() will reveal overflows on the target side; I will definitely do that. The method will not detect any data loss or bottlenecks that happen on the host PC.
    4. I will check if we have a J-Link SDK license.


    Thank you for your help!

  • Hello,

    1: The values from the Website are measured when a continuous data stream is transferred. Periodic "burst" transfers like in your setup might reach lower values.
    SWD is expected to be significantly lower due to larger overhead in the SWD protocol. We recommend using JTAG here. In theory the speed should go up linearly with the interface speed, unfortunately at some point the debug controller on the target device is not fast enough to respond to J-Link requests so the J-Link has to wait for the target. Thats why at some point the curves for the J-Link PRO no longer raise.

    2: There have been numerous changes between V5 and the current version. So it is difficult to pinpoint what exactly removed that bottleneck. Generally we suggest using the latest version.

    3: There are no data losses possible on the host PC. As soon as J-Link grabs the information from the target the data will be available on the host PC.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • SEGGER - Nino wrote:

    Hello,

    1: The values from the Website are measured when a continuous data stream is transferred. Periodic "burst" transfers like in your setup might reach lower values.
    SWD is expected to be significantly lower due to larger overhead in the SWD protocol. We recommend using JTAG here. In theory the speed should go up linearly with the interface speed, unfortunately at some point the debug controller on the target device is not fast enough to respond to J-Link requests so the J-Link has to wait for the target. Thats why at some point the curves for the J-Link PRO no longer raise.

    Is there any way to tell in advance what capability the debug controller has, for example from the datasheet of individual devices? I checked the datasheet of the part, but did not see any obvious indicators of the performance of the debug unit.

  • Hello,

    We have a model overview on our website comparing each model to each other: segger.com/products/debug-prob…nk/models/model-overview/
    More information about the individual model (electric characteristics etc.) can be found if you click on one of the model names.

    Is that what you were looking for?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • SEGGER - Nino wrote:

    Hello,

    We have a model overview on our website comparing each model to each other: segger.com/products/debug-prob…nk/models/model-overview/
    More information about the individual model (electric characteristics etc.) can be found if you click on one of the model names.

    Is that what you were looking for?

    It sounded like the limitation was due to the debug controller on the target system rather than the external debug adapter. If this is the case, the maximum data transfer rate could vary between different microcontroller models, possibly depending on how the debug controller is connected to on-chip data buses or similar ... I am not an expert in chip HW design. I was wondering if there are any easy to interpret information in microcontroller datasheets that could give an indication of what transfer speeds can be expected, besides obvious things like whether the chip supports JTAG only, SWD only, or JTAG+SWD, or the maximum output frequency of the JTAG/SWD pins.

    I tried transferring data in larger blocks (8192 bytes every 8 milliseconds) over RTT, but the transfer rate still tops out at about 300 kB/s, so I assume I am running into a limitation of the microcontroller (I am using a J-Link Ultra, with JTAG/SWD clock rates up to 25 MHz).