[support]

Hi,

This is something for you to figure out. The Arduino package structure is not specific to VisualGDB and it’s not up to VisualGDB to fix it. You can ask on the ESP32 forum – there are likely others that encountered the same problem.

[support]

Hi,

Please try running the gdb executable shown in the message (C:\Users\pdp\AppData\Local\Arduino15\packages\esp32\tools\esp-rv32\2302\bin\\riscv32-esp-elf-gdb) manually. Arduino package vendors sometimes forget to ship required libraries with their packages, leading to this type of error.

[support]

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.

[support]

Hi,

Please make sure you are using the latest VisualGDB 6.0R5. You can download it here: https://visualgdb.com/download/

[support]

Hi,

Our latest build of the ST’s OpenOCD fork is based on the 1.13.0 branch. Please refer to this page for more details.

[support]

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:

1. Does it happen with a newly created project of the same type?
2. If yes, does it happen with remotely built CMake projects, locally built CMake projects or both?
3. Does it also happen with MSBuild-based projects of the same layout (local/remote)?

[support]

Sorry about that, looks like a bug introduced in one of the recent updates. Please try this build: VisualGDB-6.0.104.5238.msi

[support]

Hi,

No problem, please try this build: VisualGDB-6.0.104.5238.msi

[support]

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.

[support]

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.

[support]

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 tests

Please make sure you are using the Custom or Ultimate edition.

[support]

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.

[support]

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.

[support]

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.

[support]

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

[Author]

Posts