Forum Replies Created
-
AuthorPosts
-
supportKeymaster
The trouble with the Arduino system is that every vendor (original AVR Arduino, ESP32, STM32, etc) ships their own packages. Often, new package versions fix some bugs from the previous versions and introduce some new bugs. Each of them has their own bug tracker, their own Github repository and their own community. So any work we put into resolving these issues will get completely obsoleted when the next package version comes out. Except, then we would get more requests for help, more issues to fix, and it would quickly snowball to the point where none of the work we do actually improves VisualGDB in the long run, and is quickly obsoleted by another update. We tried it before, we really did, and it’s just not viable, sorry.
What we can reliably offer is convenient GUI and deep integration with VS. You can configure existing package paths and not download anything new. You can choose the framework versions to download. You can decide whether to upgrade or not. You can revert to the old version if the new one is not working. We provide the GUI for all of that, but we cannot take over the maintenance work done by the package vendors. If the latest ESP32 Arduino package has broken debugging on Windows due to some missing libraries, it will remain broken until Espressif releases a fix for it.
As for our builder fork, the only modifications we introduced is accurate dumping of all GCC command lines, so VisualGDB can offer best-in-class IntelliSense that is way more accurate than any other IDE that does not have access to the underlying command lines.
As for the other IDEs, if you can confirm that the same functionality (e.g. debugging) works with another IDE on the same machine with the same versions of all libraries/packages, etc., we can help you configure VisualGDB to match that setup. But we will ask you to narrow it down to specific command lines on your own.
supportKeymasterNo problem, you can always attach to the stuck process to see what is going on inside it. Just make sure the project used for attaching has physically the same executable than the project that is actually running on the device.
supportKeymasterHi,
Please try updating to VisualGDB 6.0R6. The problem is fixed there.
supportKeymasterHi,
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.
supportKeymasterOK, 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.
supportKeymasterHi,
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.
supportKeymasterCMake 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.
November 29, 2024 at 07:19 in reply to: How can I enlarge the font for VisualGDB settings dialog? #36184supportKeymasterHi,
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.
supportKeymasterThe 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.
supportKeymasterHi,
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.
supportKeymasterHi,
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.
supportKeymasterHi,
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.
supportKeymasterSorry, 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.
supportKeymasterHi,
Please make sure you are using the latest VisualGDB 6.0R5. You can download it here: https://visualgdb.com/download/
-
AuthorPosts