Forum Replies Created
-
Posts
-
Hi,
The –set argument comes from the way VisualGDB handles the device parameters. STM32CubeIDE generates temporary scripts for each project that set some parameters and reference the original script. Our fork instead takes the –set arguments via command line so you won’t need the temporary files. The exact parameters passed via –-set come from the configuration files themselves (see the #SysprogsConfig lines in stm32_common.cfg). VisualGDB parses them, displays them in the GUI, and then passes the selections back to OpenOCD.
You can work around it by either just reusing the generated script from STM32CubeIDE, or removing the “#SysprogsConfig” lines from the .cfg files, and hardcoding them inside your device script.
OK, we have double-checked everything again.
ST appears to have some glitch with their repository. The OpenOCD binary shipped with STM32CubeIDE mentions a git commit that is not listed on Github and appears to support more devices as well. The Github repository shows the last commit in March 2024, but the git log for the same repo dates it as June 2023.
It looks like this has interfered with our release system, so the last batch of commits was not included in our last binary. We have updated it to match them. If it still doesn’t work, you can simply replace the OpenOCD binary under %LOCALAPPDATA%\VisualGDB with the exact version shipped with STM32CubeIDE. It won’t support some secondary improvements like ultra-low-latency Live Watch, but should work fine otherwise.
Hi,
We have checked the avr_debugger repository and it looks like they do support Arduino. However, you also need to flash a custom bootloader and patch the original Arduino core (note that the patches appear to be 7 years old) in order to use that.
If you can get it working via command line to the point where you can debug everything by running gdb manually, we can help you configure VisualGDB to match that setup.
CMake uses its own logic for deciding how to build each individual file, however most of it is configurable. Specifically, you can pass assembly-specific CFLAGS by using the $<COMPILE_LANGUAGE:ASM> expression in bsp_compile_flags. You can find some more examples of it in the %VISUALGDB_DIR%\cmake\embedded\bsp.cmake file.
If you cannot get anything working with CMake, you can try using MSBuild. There VisualGDB is in direct control of each compiler invocation, so you can clearly specify which tool to use in each specific case, and what arguments to pass. That said, MSBuild projects rely on a lot of legacy parts from Visual Studio itself, and are somewhat less streamlined than advanced CMake projects.
Hi,
We have switched all commonly used property pages to WPF by now, so they should look fine. If not, please attach a screenshot of the unreadable text along with a screenshot of the Visual Studio GUI that looks better, and we will look into it.
The Arduino projects are completely separate from the regular ESP-IDF projects. You can read more about them here. The ESP-IDF projects are described here.
There is no need to reinstall VisualGDB – it checks for installed packages every time you start Visual Studio. Reinstalling it does not affect the trial status.
Hi,
This should work just fine as long as the assembly files are preprocessed. If you are not sure, let us know your project type (MSBuild/CMake) and the compiler you are using, and we can suggest where to look for it.
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.
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.
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,
Please make sure you are using the latest VisualGDB 6.0R5. You can download it here: https://visualgdb.com/download/
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.
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
