[support]

Hi,

Please let us know the board you are using and we could suggest a relevant sample if there is one.

For VisualGDB projects you can setup heap/stack size via VisualGDB Project Properties -> Embedded Frameworks -> Fixed-size stack/heap.

[support]

Hi,

Thanks for the idea. This looks a bit too complicated for an immediate hotfix, however we will try to fit this into the final v5.3. We will update this post once we have progress.

[support]

Hi,

Thanks for confirming this. Could you please try adding the reference to the VisualGDB directory to msbuild command line explicitly as described here?

[support]

Hi,

Sorry about the confusion. In order to troubleshoot this please open Device Manager, locate the Olimex device and locate its Hardware ID (via Properties window). Then please check the USB VID and PID shown in the Hardware ID against the IDs specified in the .cfg file. Can you confirm that the IDs match?

If yes, which driver is installed for the Olimex interface?

In order to use automatic connection testing, please update to VisualGDB 5.3 and install the latest ESP8266 toolchain. It includes an updated debug mechanism that detects and fixes most of the driver problems automatically.

[support]

Hi,

Looks like you might be using a deprecated version of the script. Please try using interface/ftdi/olimex-arm-usb-ocd.cfg.

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

[Author]

Posts