[support]

Hi,

Please try clicking “Change” in the installer and selecting both VS versions. If this doesn’t work, please uninstall VisualGDB and then run the installer again. This will preserve your settings, downloaded packages and other data.

[support]

Hi,

You might be missing the “aggressive completion” option (press Ctrl+Space in the text editor and click on the lightning symbol in the completion popup to enable it). If this doesn’t help, please let us know more about what exactly do you expect/observe.

Generally, we advise using our Clang engine over the native VC++ one, as it’s specifically optimized for GCC-specific code and also provides various advanced features like create-from-use, CodeJumps, instant go-to-definition and mode. You can read more about the Clang IntelliSense highlights here: https://visualgdb.com/?features=intellisense

[support]

Hi,

Yes, please use the Tools->Options->VisualGDB->SSH->Executable Extensions setting.

[support]

Hi,

No problem and thanks for the kind words. Please try the build posted in this thread.

[support]

Hi,

No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2627.msi

We have added a quick workaround for this. Please create a separate project and configure the deployment via custom pre-debug steps, then copy the <CustomDebug> element from the .vgdbsettings file into the %LOCALAPPDATA%\VisualGDB\QuickDebugPresets\<preset>.quickdbg directly under the QuickDebugPreset element.

We will add the proper GUI for editing those steps from the QuickDebug window in the next major VisualGDB release (after v5.4) as a part of our redesign of the QuickDebug GUI.

[support]

Hi,

The screen shown in s2.png means that the target is stopped at a location that doesn’t have any source files associated with it. It should not interfere with anything – you can press F5 to continue debugging, or use the GDB Session window to enter further gdb commands.

[support]

No problem. We have retested the uninstaller on the latest x64 Windows 10 and updated it to properly remove the entry from the “Add/Remove Programs” list and also delete the mkisofs.exe file. Please note that the files that are in use during the WinCDEmu uninstallation will be removed next time you restart Windows.

[support]

Hi,

Yes, please try disabling the “Redirect printf() to semihosting” flag via VisualGDB Project Properties -> Embedded Frameworks and then manually define the “FAST_SEMIHOSTING_STDIO_DRIVER=1” preprocessor macro for the Debug configuration where you want to have semihosting enabled.

Please note that you can also configure the profiler framework to ignore semihosting calls when no debugger is attached (works with most Cortex-M devices) using a corresponding setting on the Embedded Frameworks page.

[support]

Hi,

Thanks for the update. It looks like OpenOCD does get an incoming connection from gdb, so the problem should not be caused by the firewall (OpenOCD likely ends the connection when it discovers some critical error without showing more details).

If OpenOCD works with another board, we would advise comparing the schematics of the 2 boards and checking JTAG signals on both boards with an oscilloscope.

[support]

Hi,

As OpenOCD doesn’t mention an incoming gdb connection, it looks like something (likely a firewall or antivirus) is blocking it. Please try disabling your firewall/antivirus software and try again. Please also consider starting a debug session and checking the logs from both gdb and OpenOCD (double-check that both are using the same TCP port). If the OpenOCD does show the “incoming gdb connection” message, please share the updated log and we will help you find the relevant message.

[support]

Hi,

Please try updating to VisualGDB 5.4 Preview 10.

[support]

Hi,

Sorry, not currently. This Thread & ZigBee SDK appears to be much less popular than the regular Nordic SDK, so we won’t be supporting it directly unless it’s merged into the mainline SDK, becomes more popular, or someone orders it via our custom BSP program.

Please consider creating a project manually as shown in this tutorial: https://visualgdb.com/tutorials/arm/legacy/

[support]

Hi,

VisualGDB-generated projects contain all necessary code inside the main .c or .cpp file, hence they do not need separate _it.c and main.h files.

If you get errors due to missing _it.c file, most likely you have replaced the main source file with the main file from another project that also includes the _it.c and main.h files. If this is the case, please ensure you copy ALL the relevant files from the project you are trying to import.

[support]

Hi,

You can disable the automatic activation of the GDB Session window via Tools->Options->VisualGDB->General->GUI->Don’t Activate GDB Session window.

We have also added an option under General->Debug to ignore the inline gdb stub output to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2623.msi

[support]

Hi,

Thanks for reporting this. We have investigated it and it looks like the behavior for missing source paths has changed in a recent VS update. The file path actually comes from the debug symbols in the libraries on Raspberry Pi and it indeed does not exist on your machine. The previous VS versions would ask for the path of the file, but it looks like the latest VS build shows an error instead.

We have addressed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2623.msi

VisualGDB will now report frames referencing non-existing frames as assembly-only (you can override this via Tools->Options->VisualGDB->Common->Debugging->Hide Missing Source Files).

[Author]

Posts