Forum Replies Created
-
Posts
-
Hi,
If you believe VisualGDB is working incorrectly, please provide complete unambiguous steps to reproduce the problem from scratch. The steps should start with creating a new project, and should either mention every involved setting, or include screenshots of every involved wizard/settings page and every other change. They should also include any relevant logs.
Please see our problem reporting guidelines for more details.
Hi,
This is by design. Unless you do a full rebuild, the build system only builds the files that are out-of-date (i.e. the sources have changed more recently than the objects). Files that are up-to-date are not rebuilt and the warnings that were shown during their compilation will not be shown again unless these files become out-of-date again. This is standard behavior for all build systems we are aware of and is not specific to VisualGDB.
Hi,
This looks like an internal error in GNU Make itself. The easiest workaround would be to switch to a different project type that does not use Make (e.g. MSBuild or CMake + Ninja).
Hi,
The MSP430 support in VisualGDB is implemented via an open-source tool called msp430-gdbproxy. Although it currently only supports erasing the entire FLASH memory, you can easily modify it to erase a custom range instead.
You would need to clone the msp430-gdbproxy repository and edit the MSP430Target.cpp file to support an additional command (e.g. “erase_range”). Then you can remove the original “erase” command from the <sysgcc>\msp430\msp430-bsp\debuggers\core\edp.xml file and add a custom “erase_range” command to VisualGDB Project Properties -> Additional GDB Commands.
No worries and good to know it works. We have updated our documentation to explain the color coding of exportable command lines to avoid any further confusion.
Yes, clicking on “Dump command line to Batch File” should open a dialog asking for the location of the .bat file. If this doesn’t happen, please try attaching a screenshot of the build window showing the context menu with the “Dump command line to Batch File” option.
Hi,
VisualGDB should normally fill the stack automatically as long as you enable the option in Embedded Debug Tweaking.
Once a breakpoint in main() is hit, it will try to find one of the following symbols in the order shown below: __StackLimit, end ,_ebss, _edata. Then, it will fill the area between the first found symbol and the current value of $sp, and will begin monitoring it. The __StackTop or _estack symbol will be used to determine the total stack size.
BTW, the stack monitoring logic is implemented in our open-source Live Watch plugin, so you can always tweak it if you would like to support special project layouts.
Hi,
VisualGDB 5.6 Beta 3 already supports it, as long as you our latest ESP32 toolchain, ESP-IDF 4.3 and the most recent OpenOCD package.
Sorry for confusion. If OpenOCD is running on a Linux machine, indeed the “dump_image” command with a Windows path won’t work.
The easiest way to get it working would be to port the mbatch command from our OpenOCD fork (see this commit). You may need to adjust the code slightly, since the interfaces used by OpenOCD to implement custom commands change from version to version. You can use this fork as a reference. Once VisualGDB detects that OpenOCD supports the mbatch command, it will keep using it instead of dump_image.
Hi,
We have just rechecked the latest ESP-ADF framework. Just as our tutorial mentions, it doesn’t work with the latest GCC 8.x, but does work if you install GCC 5.2.0. This happens because ESP-ADF is based on an older ESP-IDF, that expects that specific old compiler version. Most likely, you ended up using GCC 5.2.0 with VS Code and GCC 8.x with VisualGDB.
Please double-check your GCC versions in the toolchain selection drop-down and make sure you are using GCC 5.2.0 with ESP-ADF as explained in the tutorial.
Hi,
As you have never provided the complete non-ambiguous steps to reproduce the problem from scratch, all we could do is re-run our standard coverage tests on a STM32CubeMX project during the v5.6 Beta 3 release cycle. They did uncover a glitch that could be causing this issue and we have fixed it in the Beta 3. Please try downloading and installing it from the download page.
Hi,
Sorry, this is by design. The “transfer files” command is intended for transferring them to/from Linux hosts and will not work between 2 local directories.
As a workaround, please consider launching xcopy.exe as a custom pre-build step to copy files within the Windows machine.
Hi,
Please double-triple check that you are importing the correct project. The import logic of the wizard never generates any new files, it simply references existing files linked by the project file. You can find out the full path of the file containing the main() function by right-clicking on the tab header in Visual Studio and selecting “Copy full path”. You can then compare it with the path of the file in the original STM32CubeIDE project.
