[support]

Hi,

Sorry, we have rechecked this and could not reproduce any problem. Please try switching the terminal to the hex mode and ensure that the ‘escape’ character is transmitted properly.

E.g. try transmitting exactly the line shown in our previous post and verify that the HEX view shows the following output:

74 65 73 74 0a 1b 5b 31 3b 32 48 32 1b 5b 31 3b 31 48

[support]

Hi,

Sorry, this is not supported directly. We have done some basic experiments with the 2-core LPC43xx devices and the biggest problem we encountered was that the 2 cores required 2 separate copies of the C library (compiled for 2 slightly different instruction sets) that could not be easily merged into a single ELF file, so the current out-of-the-box support it limited to the M4 core.

As a workaround, please consider following the legacy device tutorial to create a project manually (or simply import one of the code examples from NXP) and then edit the OpenOCD configuration script for the MCU to leave out only the M0 target (or use Segger J-Link and pick “LPCxxxx_M0” as the target device). Although, due to the limitations of the gdb, you won’t be able to easily debug both cores at the same time.

[support]

Hi,

Yes, the X server might be running on a different port. Please try starting a GUI terminal (e.g. xterm) via the USB keyboard/HDMI port on Raspberry Pi, and type “echo $DISPLAY” to see the display number used by your board. If the number is not 0, simply copy it to the corresponding field in VisualGDB Project Properties.

Please also ensure that the user name used in VisualGDB to connect to your Raspberry Pi matches the user account running via the HDMI port (normally ‘pi’).

[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++?

[Author]

Posts