support

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 6,948 total)
  • Author
    Posts
  • in reply to: First "-var create" call takes too much time #32721

    support
    Keymaster

    Thanks for checking it. VisualGDB simply opens the TCP listener at the first available port, and then tells the WSL launcher to connect to it. You can try testing it out with the following C# code on the Windows side:

    If you cannot telnet to the port reported by IPEndPoint from WSL, please try finding out which ports work, and looking for settings that could be affecting the broken port ranges.

    in reply to: Debugging for esp8266 through jtag? #32718

    support
    Keymaster

    Hi,

    Please note that we are not the vendor for the ESP8266 chip.

    If you have questions about the ESP8266, please consider contacting Espressif directly.

    in reply to: Exception on opening "VisualGDB project properties" #32716

    support
    Keymaster

    Thanks for the clarification. We have managed to reproduce the behavior – indeed VisualGDB was ignoring the “build” flag in Solution Explorer when enumerating test projects.

    We have fixed it in the following build: VisualGDB-5.6.105.4604.msi. Please note that if you change the build flags while the solution is open, you would need to reopen it or close and reopen the Test Explorer window in order for the changes to take effect.

    in reply to: STM32h753 External Memories Loading #32715

    support
    Keymaster

    Good to know it works with ST-Link.

    J-Link is generally better than OpenOCD out-of-the-box (with its own software), but the FLASH plugin interface is indeed specific to OpenOCD.

    OpenOCD support for J-Link devices uses a separate open-source implementation that might contain its own bugs. If switching to ST-Link solves the problem, it could be a reasonable workaround.

    in reply to: IMXRT1050-EVKB Settings #32714

    support
    Keymaster

    If the image produced by VisualGDB is not working, while the same project built with MCUXpresso works with the same uploading/debugging method, most likely the two projects are using different memory layout. VisualGDB imports the default settings from the MCUXpresso SDK, and the SDKs generated for the MCUXpresso IDE and generic GCC (used by VisualGDB) could be slightly different.

    As suggested in our first reply, you can try using the objdump tool to dump the layouts of both projects into text files, and compare the addresses of the critical parts (vector table, stack pointer, initialization code, etc.). If they are different, please double-check the linker scripts used by both versions of the project and make sure they are consistent with each other.

    Ultimately, both MCUXpresso and VisualGDB use the same GCC compiler, so if the executables produced by them are different, some arguments to the compiler do not match between the 2 setups. Running objdump could help track it down, and you can also try running the command lines from both sides manually as shown in this tutorial (it is about Keil, but the VisualGDB-side steps for the GCC compiler will be similar).


    support
    Keymaster

    This looks like you have configured some extra settings in the project to incompatible values.

    Please try reproducing the problem on a project created from scratch. If the problem persists, please let us know the steps to reproduce it per our problem reporting guidelines. If the newly created project works, please try comparing its settings against the current project settings and make sure they match.

    in reply to: STM32h753 External Memories Loading #32706

    support
    Keymaster

    Hi,

    You can find the logic used by OpenOCD to load and run the plugin in this file: https://github.com/sysprogs/openocd/blob/master/src/flash/FLASHPlugin.c.

    You should be able to understand what is going on by building a debug version of OpenOCD and running it under debugger (see this tutorial).


    support
    Keymaster

    You can work around it by creating an empty .c file and referencing it from the targets that would otherwise have no sources. Another solution would be to patch CMake to make it report interface libraries together with the object libraries, but that could be rather complicated.

    in reply to: [-Wdeprecated-declarations] #32703

    support
    Keymaster

    Hi,

    The exact location of the setting depends on your project type. Please see this page for more details. You can also double-check whether the option gets actually passed to the compiler by enabling verbose build (see project type-specific pages linked above) and rechecking the GCC command lines.

    in reply to: First "-var create" call takes too much time #32702

    support
    Keymaster

    Hi,

    Normally, WSL2 should work out-of-the-box, as long as the Linux side can connect to the Windows side via TCP/IP. Please see this page for a detailed instructions on troubleshooting WSL2 issues.

    in reply to: STM32h753 External Memories Loading #32701

    support
    Keymaster

    Hi,

    You are likely missing the “init” command. In general, we would advise first running OpenOCD using exactly the same command line VisualGDB uses, then connecting to the telnet_port via telnet and running the “mdw” command via it. This should produce results consistent with regular debug sessions.


    support
    Keymaster

    Hi,

    This is a known limitation of CMake. It indeed does not report the contents of interface targets via the mechanism used by VisualGDB.

    Please consider using object libraries instead – they work similar to interface targets, but their contents is actually shown.

    in reply to: Pre-/Pos-Build Events #32693

    support
    Keymaster

    Hi,

    VisualGDB has its own easy and intuitive mechanism for custom steps. You can use the “Custom build steps” page of VisualGDB Project Properties to define a variety of different steps using convenient GUI.

    Note that this feature is available starting from the Custom edition.

    in reply to: First "-var create" call takes too much time #32692

    support
    Keymaster

    Good to know you managed to reproduce it. One thing, issues like this could be caused by bugs in the network stack (packet with the command from VisualGDB gets lost and is never resent). If the issue happens intermittently over SSH, but never locally (e.g. in an xterm window), it could be caused by the network rather than the gdb executable.

    in reply to: First "-var create" call takes too much time #32683

    support
    Keymaster

    Hi,

    This message means that your gdb debugger is taking too long to process the variable evaluation command issued by VisualGDB. The delay does not come from the VisualGDB side and it caused by the gdb itself.

    If you would like to find out what is causing it, please consider building a debug version of your gdb executable and stepping through it once you reproduce the issue.

Viewing 15 posts - 16 through 30 (of 6,948 total)