[support]

Hi,

Thanks, we have rechecked this and can confirm that despite VisualGDB only querying the values for the children physically shown on the screen, gdb takes considerable time to evaluate the first batch.

We have added a workaround to the following build: http://sysprogs.com/files/tmp/VisualGDB-5.3.8.1792.msi

[support]

Hi,

No problem. If the same gdb works with command line, we would recommend double-checking the following:

• The exact command lines when launching gdb and gdbserver
• Environment (e.g. LD_LIBRARY_PATH)

Please also try switching gdb start mode to ‘custom’ and explicitly specify the ‘target remote ….’ command. Then launch gdbserver manually and let VisualGDB launch gdb. If the problem persists, it is caused by gdb configuration, if not – it’s caused by gdbserver launch configuration.

You can use the View->Other Windows->VisualGDB Diagnostics Console command to see the internal VisualGDB output showing the commands it runs.

[support]

Hi,

The ARM-USB-OCD and ARM-USB-OCD-H devices have different USB IDs. Please try enabling the manual script selection and select the olimex-arm-usb-ocd.cfg script explicitly.

[support]

Hi,

Good to know it works. Normally reinstalling VS2017 and ensuring you can create regular VC++ Win32  projects should help as well (the regular VS wizard uses the same mechanism).

[support]

Hi,

The Sysprogs.Build.Tasks assembly actually imports many methods from VisualGDB.exe (VisualGDBCore.dll on v5.3+). Please ensure that this assembly is also present in the Sysprogs\VisualGDB directory.

[support]

Hi,

Most likely your PLL settings don’t match the correct ones for your board, so the USB ends up being clocked with an incorrect frequency. We would recommend selecting “STM32CubeMX samples” on the Sample Selection page of the Wizard and then pick a sample that matches your board.

[support]

Hi,

Looks like the OpenOCD build you are using does not support your device yet. Normally support for new devices is added to OpenOCD several months after the device is announced; then the updated version get picked up by our build system and released as a VisualGDB package.

If you don’t want to wait, we could easily walk you through building OpenOCD from sources and modifying it to support the device manually (it only requires specifying the FLASH size for your device ID so that OpenOCD can detect it).

[support]

Hi,

Please update to VisualGDB 5.3 Preview 8. The latest ESP32 toolchain is not compatible with v5.2.

[support]

Hi,

Thanks for your feedback. We will re-investigate Arduino support after the final release of v5.3.

[support]

Hi,

In order to add MSBuild variables, you would need to edit the .vxcproj file as follows:

  <PropertyGroup>
    <VariableName>VariableValue</VariableName>
  </PropertyGroup>

The settings from Embedded Project page get written to the mcu.props file after you change them (VS would not display those in VS project properties) and apply to all configurations inside a project.

The settings from the MSBuild settings page get saved in the .vcxproj file and are applied to each configuration independently.

[support]

Hi,

Please check the GDB stub output (e.g. Segger GDB stub) via Debug->Windows->GDB Stub. It should contain detailed information about the error.

[support]

Hi,

By regular, do you mean the Linux edition? If yes, please create a normal cross-compilation project as shown here and modify its debug settings so that it will debug your application instead of its build output (that should be ignored). Note that you would need to manually copy the built ELF file from the Linux machine to the Windows machine so that the Windows gdb can load it.

[support]

Hi,

Thanks for checking this. It actually looks like despite enabling Clang IntelliSense, your project might not be using it (Clang error messages should be prefixed with [Clang IntelliSense]). Could you please post the screenshot of the entire VS window and the contents of View->Clang IntelliSense Diagnostics Console so that we could check that it got loaded properly?

[support]

Hi,

Thanks for the screenshot. This is a known bug in the MSP432 driver library. Please locate the debug.h file and change the definition of ASSERT() to always ignore the argument:

#ifdef DEBUG
#define ASSERT(expr)
#else
#define ASSERT(expr)
#endif

or simply

#define ASSERT(expr)

 

[support]

Hi,

This could happen if your gdb and gdbserver were not 100% compatible. Please ensure that your gdbserver comes from the toolchain provided by your device vendor. If not, we would recommend either debugging directly on the device, or building a gdb binary using the same sources (including Debian patches) and the same settings as your target gdb has.

[Author]

Posts