Posts by RTTseemsOK

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

    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”.

  • 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.

  • [SOLVED] Trouble connecting JLink USB in Linux dev container

    Solved.

    The very short answer is that Docker Desktop for Linux is not ready, don't use it. At a very minimum it does not seem to pipe USB or /dev through even when specifically requested.

    Uninstalled it. Installed the engine and utils instead. Had to edit .docker/config.json to remove "credsStore", but now it works perfectly in VS Code. USB pipes through with no special work in the Dockerfile or devcontainer config.

  • [SOLVED] Trouble connecting JLink USB in Linux dev container

    My OS is Linux Mint 21.2, using Docker Desktop. I'm working with VS Code remote containers. My container has JLink installed with dependencies with notes from this thread UDEVADM JLink Container Solution.

    Using root user and a basic container to get things up before dialing down, I can't seem to access my USB JLink.


    This does work under my OS installed JLink outside of the container.

    I'm not sure what to try next. Is there a log somewhere?

    Has anyone had this issue?

    Maybe a permissions recommendation? The container is marked as privledged in VSCode ("privileged": true in devcon json).


    Support info:

    1. In my linux desktop I have a /dev/bus/usb/021 which is currently my JLink (no persistent name, but that's OK for now). In my Container I have no matching folder. I assume there may be differences in my Linux Mint (Ubuntu based) Desktop and Ubuntu 22.4 Container... But I think this is a big clue. I don't seem to have USB in the container... Looking for a solution because Segger's own container guide doesn't mention this at all.


    2. I noticed other JLink Utils will not start. I suspect this is because most of the pop up a GUI? These do work in my OS version.

    Code
    root@ae1709e223cc:/# JLinkGDBServerExe 
JLinkGDBServerExe: error while loading shared libraries: libXrandr.so.2: cannot open shared object file: No such file or directory
root@ae1709e223cc:/#

    3. Somehow and from somewhere, a .reg file was created on my linux container's root folder. No idea what this is!


  • [ABANDONED] Reset to a specific ROM address?

    I assume that JLink reset command or GDB reset will get the micro to a default state. But what if I linked my code at a specific address and there is nothing at the default rom address?

    An IDE seems to hard fault, as it will send this basic reset, and the PC will jump to a location with no code.

    Is there a way to reset to a known/set state? I looked up reset strategies and didn't see much that was relevant to code (a vector table) missing from a default rom address.

    Thoughts?