[support]

Hi,

You can always achieve this by creating custom MSBuild targets via editing the .vcxproj file. It is much less straight-forward than the custom steps provided by the VisualGDB Custom Edition, but will work just fine once you get familiar with the MSBuild internals.

[support]

Hi,

It looks like your support period has expired. Please kindly renew it here and we will be happy to help you.

[support]

There is no need to regenerate the batch files unless you change global parameters, such as the toolchain or the environment. The batch files simply invoke CMake to parse the CMakeLists.txt files, generate the actual build rules, and then build the project with them. This workflow will automatically pick up any changes in CMakeLists.txt and the source files.

Here’s the contents of a typical batch file for CMake:

cd /d C:\projects\temp\DemoProject\build\VisualGDB\Debug
set LANG=en_US.UTF-8
set PATH=c:\SysGCC\arm-eabi\bin;%PATH%
set TOOLCHAIN_ROOT=c:/SysGCC/arm-eabi
set EFP_BASE=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/EmbeddedEFPs
set TESTFW_BASE=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/TestFrameworks
set TESTFW_BASE_LOCAL=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/TestFrameworks
"C:\Users\virtual.SYSPROGS\AppData\Local\VisualGDB\CMake\bin\cmake.exe" ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DTOOLCHAIN_ROOT=c:/SysGCC/arm-eabi -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe" -DCMAKE_TOOLCHAIN_FILE=<...>/toolchain.cmake -DPLATFORM=VisualGDB -DLOCALAPPDATA=C:/Users/virtual.SYSPROGS/AppData/Local

It references various common paths and the toolchain.cmake file, but doesn’t contain anything that would change when you add a new source file or a target.

[support]

Hi,

This looks like your VisualGDB installation is corrupt. Please make sure you are using an unmodified installer and do not edit any files or registry entries.

If nothing helps, please attach a screenshot of the Help->About VisualGDB window.

[support]

Thanks, this is a different issue. When using the VisualGDB.exe /build or /rebuild command for Advanced CMake projects, it was not properly passing the build type to CMake, so it ended up building the debug configuration (despite using the release folder).

We have fixed it in this build: VisualGDB-5.6.3.4195.msi

We also recommend building Advanced CMake projects by dumping the build/configuration command lines to batch files as shown here.

[support]

Please double-check the values of __StackLimit  and __StackTop  per our previous reply.

[support]

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.

[support]

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.

[support]

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

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[Author]

Posts