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

[support]

Hi,

No problem. The easiest way to do this would be to use Debug->Quick Debug command (requires Custom edition) and select:

• Target: Linux system
• Use a cross-compiler on the Windows machine

Then VisualGDB will let you choose a toolchain containing the gdb. Simply click “locate a cross-toolchain by finding its gdb.exe” and point it to your gdb executable.

If you use regular VisualGDB projects to build your project, we can help you configure them as well. Do you use the regular “start a new instance” setting?

 

 

[support]

Hi,

A cross-gdb is a Windows build of gdb targeting your Linux machine. You can normally obtain it by downloading the sources for the same version of gdb as your Linux VM uses (applying Debian patches if relevant) and building it on Windows from a MinGW shell (you would need to specify target and the target options to 100% match the configuration of your Linux gdb).

As a result you will get a gdb.exe that can run directly on Windows and communicate to the remote target via the gdbserver protocol.

You can also try using one of the gdb binaries from this archive, however they may end up being incompatible with your target due to incompatible flags.

 

[support]

Hi,

It’s hard to say what could be causing it without knowing the context (it could be a typo in the device library, incompatible setting, old gcc or a missing #define somewhere). Please let us know which device family you are using and attach a screenshot of the source file with the line causing the error and we will help you resolve this.

[support]

Hi,

VisualGDB itself does not have any limits on command line lengths (it actually uses response files to avoid any implicit limits set by Windows).

The behavior you are experiencing might be caused by the WinForms text box control used across VisualGDB settings. Please try using the VS project properties instead (or edit the .props file manually).

[support]

Hi,

Thanks for the screenshots. At the first glance, the 2 projects look equivalent. Can you confirm that opening one of them with VS2017 works and the other one opened with VS2017 fails?

The message box you attached looks like it’s produced by Visual Studio before and VisualGDB logic gets triggered, so most likely it is caused by either corrupt MSBuild platform definition, or some installation-related problems. Uninstalling and installing back VisualGDB (and VS if this doesn’t help) might resolve this.

[Author]

Posts