[support]

 

Hi,

Sorry, looks like you have omitted the stack trace (lines underneath the exception name) that contain information necessary to pinpoint the source of this. Please attach them as well and we should be able to see what is going on.

If you are not sure, please post a screenshot of the error message as it is shown.

[support]

Hi,

Thanks for checking it – that explains what is going on. Looks like VisualGDB indeed cached the values from the previous compiler.

Please click “Regenerate MSBuild Files” on the MSBuild Settings page of VisualGDB Project Properties, or simply delete the IntelliSense.props file and reopen the project to regenerate the toolchain files.

[support]

Hi,

This looks like a problem that was recently fixed. Please try the latest daily build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2400.msi.

[support]

Hi,

Sorry, we are still investigating this. Please expect an update on Monday-Wednesday.

[support]

Hi,

Thanks for your input. There is actually a setting for this already: Tools->Options->VisualGDB->Common->GUI->Don’t Activate GDB Session Window.

However VisualGDB displays various debug-related errors and progress status in the GDB Session window, so we normally recommend keeping it visible (or at least checking it if you encounter strange behavior).

[support]

Hi,

VisualGDB already supports the ANSI escape codes. We have tested the following code with STM32 and it was properly outputting “t2st”:

 printf("test\n\x1b[1;2H2\x1b[1;1H");
 fflush(stdout);

There was, however, a bug where the semihosting console state was not properly reset if the previous debug session contained invalid/incomplete escape codes. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2400.msi

[support]

Hi,

Thanks for reporting this. We have fixed individual target building when using Ninja (and also improved it for regular GNU Make). Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2400.msi

[support]

Hi,

No problem and thanks for your feedback. We have added the ‘Properties’ command to ESP-IDF components in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2400.msi

Let us know if you have further usability-related feedback and we will be happy to make VisualGDB even better.

[support]

Hi,

Unfortunately this is a limitation of the Segger gdb stub. In order to avoid race conditions between live variables and the actual debugger, VisualGDB needs to use a relatively slow memory reading interface.

You could try manually changing the UseUnreliableLiveMemoryEngine node in the .vgdbsettings file to force VisualGDB to use a faster memory access mechanism, however it could cause random crashes and/or unexpected behavior.

[support]

Hi,

Good to know it works.

Most of the pages look better on high-DPI displays as we have switched them to a more modern WPF technology. The Debug Settings page is one of the next property pages on our WPF conversion list.

[support]

Hi,

Sorry, this is a known limitation. Please update to VisualGDB 5.4 Preview 4.

[support]

Hi,

Thanks for the screenshots. Looks like the Clang IntelliSense is successfully initialized.

Please try locating the following file:

%LOCALAPPDATA%\VisualGDB\ToolchainProfiles\<host name>\com.sysprogs.toolchain.default-gcc-\IntelliSense.props

Does the __cplusplus value recorded there match what you expect? Are you using the correct “language standard” setting in VS Project Properties -> C/C++?

[support]

Hi,

Thanks for reporting this, looks like our bug introduced during a recent LXSS-related fix. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2398.msi

[support]

Hi,

Thanks for confirming this. We have fixed the programming port location logic in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2396.msi

If you want to be able to clone the library into the Arduino libraries folder, please consider moving your Visual Studio solution (and VisualGDB project) into a subdirectory instead (e.g. examples). It cannot be the same directory as the sketch files though, as Arduino will try to copy it recursively to the build directory. If this doesn’t help, let us know and we will try to suggest something better.

VisualGDB does provide a built-in terminal (Raw Terminal in VisualGDB Project Properties), although it is only available in the Custom edition and higher. If you are using a lower edition, please consider our free SmarTTY tool. It is functionally equivalent, although will run in a separate window and won’t be synchronized with launching the project.

[support]

Hi,

Thanks for reporting this, looks like our bug. We have updated our BSP generator to include this register in the next BSP release (expected within the next month).

As a workaround, please try replacing the stm32l432xx.xml.gz file in your BSP directory with this one: http://sysprogs.com/files/tmp/stm32l432xx.xml.gz

[Author]

Posts