RTT 50ms timeout is too short for linux container pass-through

    * Running an STM32 device

    * JLink Ultra to Linux host machine over USB and SWD

    * VS Code remote dev container (docker) for my environment, cortex-debug extension in VS Code to active and use JLinkExe. So USB is tunneled inside to docker (linux to linux)

    * Docker exposing port 19021. HOST USB >> CONTAINER >> TCP 19021 >> HOST. It's a little weird, but the benefits of embedded with remote container can not be oversold.

    * RTTViewer is activated on my host machine

    * Using CONNECT TO EXISTING when I have a debug session open in VS Code.

    * RTTViewer will most of the time report the error: "J-Link DLL did not send welcome string in time."

    * If you spam the connect attempt, it will occasionally connect.


    SUSPECTED: That Segger RTTViewer will timeout at 50ms. This is likely enough time for most people but I have a lag somewhere. When I spam the CONNECT button and blow through the errors, occasionally it will connect because randomly connections make it under timeout.

    SOLUTION: I need this to be a variable or otherwise extended.

    WORKAROUND: I don't know why the connection is so slow, I could look into that?


    VIDEO:

    External Content vimeo.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    WIRESHARK DATA:

    The first three attempts, the SYN/SYNACK is the same, but the PUSH never comes, so after 50ms, the Viewer kills the connection with a FIN.

    LINE 28/29, this time the PUSH comes at 38 milliseconds for whatever reason. This seems to be under the 50ms timeout that Segger put in place. Now it works fine.

    I don't know what loopback from container to PC timing should be. However, the timeout seems too show for most networking this connection over internet, I'm not sure that is common but it wouldn't work there either.

    EDIT: Tried to use Docker `--network=host` makes the whole thing unconnectable even with spamming the connect button.

    Edited 2 times, last by RTTseemsOK: Added test for docker settings. (July 26, 2024 at 10:59 PM).

    I could still use help on this. Ideally there would be a way to adjust the timeout, otherwise, if someone could adjust in it a new build that would be good too.

    Or even more ideally... Maybe this project is updated as a Tabby plug in or something a little more versatile?

    It might not be the solution for your setup, but I am using JLink GDB Server and RTT Viewer on the host and connect to the GDB Server on the host from within the docker container. The marked line in the launch.json shows the connection to the GDB server for downloading and debugging, RTT is done on the host side. Hope that helps.

    "configurations": [
    {
    "type": "cortex-debug",
    "request": "launch",
    "servertype": "external",
    >> "gdbTarget": "host.docker.internal:2331", <<

    "name": "Jlink",
    "device": "nrf9160",
    "interface": "swd",
    "rtos": "Zephyr",
    "runToEntryPoint": "main"
    },

    I’m already attaching to GDB inside the container.

    The issue is rather that the telnet from docker to host adds too much latency for RTT Viewer.

    All I would need is a single byte change, but obviously this would be reverse engineering discussion and that is strictly forbidden on this forum!

    I have a workaround for now. But it would be great if Segger realized that 50ms arbitrary and too fast for edge cases and made this an argument or just increased it.

    It’s not even my biggest issue with RTT Viewer. The auto connect and re-up from old sessions needing be manually cleared on all 16 of the virtual terminals is worse I think.

    I figured I would start with the “easy one”.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login