Forum Replies Created
-
Posts
-
Sorry, we couldn’t reproduce that one. Most likely, it is caused by something else. In order to narrow it down please try checking the following:
- Does it happen with a newly created project of the same type?
- If yes, does it happen with remotely built CMake projects, locally built CMake projects or both?
- Does it also happen with MSBuild-based projects of the same layout (local/remote)?
Sorry about that, looks like a bug introduced in one of the recent updates. Please try this build: VisualGDB-6.0.104.5238.msi
Hi,
No problem, please try this build: VisualGDB-6.0.104.5238.msi
Thanks, please try this build: VisualGDB-6.0.104.5238.msi.
VisualGDB will now expand per-user variables in the COM port and Baud Rate setting, so you can set the COM port to something like $(ESP32ComPort) and it will have different values for different users.
Sorry, it doesn’t look like any known issue and is likely caused by some rare combination of settings that is hard to deduce from the description you provided.
The easiest way to troubleshoot it would be to try creating a new similar project from scratch, and checking if the problem persists. If the problem does not happen on a newly created project, please try comparing the settings files between the working and non-working projects. Many problems are caused by very minor differences in settings.
If you can confirm that the problem persists on a newly created project, please let us know the steps to reproduce it, including the detailed screenshots of every step you do and every error message you get. If we can follow them on our side and get the same problem, we should be able to fix the issue or suggest a workaround.
Hi,
It looks like you are trying to use a VisualGDB edition that does not support unit tests:
2024-11-21T21:23:12.0360628Z Build/launch failed: Your edition of VisualGDB does not support unit testsPlease make sure you are using the Custom or Ultimate edition.
Hi,
This one is tricky. VisualGDB projects are designed to be debuggable outside Visual Studio as well (e.g. to run tests or record traces), so the debug engine does not receive the regular Visual Studio variables.
VisualGDB-level variables (e.g. $(ProjectDir)) will work and you can also pass arbitrary variables via environment. The $$SYS:MCU_ID$$ syntax is used for BSP-level variables (that are not specific to a particular project) and are used for tasks like translating the same BSP definition into both CMake rules and MSBuild rules.
Hi,
It could be possible to do this via user variables. Feel free to let us know your the project type so that we can provide more details.
Yes, this means it is working correctly.
On a second thought, do you have the “sudo” explicitly specified as the build command? If yes, it actually won’t work unless sudo is configured to run without asking for password for this user.
When VisualGDB decides to use sudo (there’s an option to enable it for debugging, but not for building), it uses special workarounds to handle sudo prompts, that won’t work if you just specify “sudo” as a part of the command line.
The plugins are included with VisualGDB and will work out-of-the-box. The only reason why we publish the sources is so our users can tweak them to some specific cases (e.g. using a custom queue class and wanting to plot its utilization without stopping the program).
Hi,
VisualGDB does fully support ThreadX and FreeRTOS object view. It actually users a special memory reading mechanism that works without interrupting the target, so it can display the state of various objects while your program is running. See this tutorial for more details.
Both thread plugins are open-source, so you can tweak them to a particular project.
That said, it is an advanced feature that requires the Custom edition or higher. If you are using a lower edition, you can always upgrade here.
Hi,
VisualGDB handles WSL by launching a monitor process on the Linux side that forwards the actual application output back Windows via TCP. The most likely explanation why it’s not working is that the firewall either on Linux or Windows side is preventing VisualGDB from connecting to it.
If turning the firewall off doesn’t work, you can try narrowing it down by running VisualGDB.exe /lxsstest. It will run the “uname -a” command inside WSL, but will launch the monitor process in a separate window, so you can check if it does anything suspicious.
Hi,
You can just patch the linker script file under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs.
If you want to fix it for multiple devices, you can try regenerating the entire BSP from the STM32 SDKs using our BSP generator. However, it involves some manual setup (e.g. downloading STM32CubeMX) and will download huge SDK packages from ST.
Hi,
You can try this build: VisualGDB-6.0.104.5230.msi. It uses relative paths for BSP sources, include directories and linker scripts, as long as they are within the project directory.
Hi,
The procedure for getting exactly the same output would be to compare the builds, narrow down on specific differences, and track each of them to the root cause. That said, the ELF files will not be 100% equal due to source file paths stored in them, and the symbol in the final binary could be in a different order if the linker does not pick them deterministically.
