Forum Replies Created
-
Posts
-
Hi,
VisualGDB uses different synchronization logic for different files/directories. E.g. the files in the source directory are only synchronized one way (Windows to Linux). Stepping into a source files that is not normally synchronized will get it temporarily downloaded under %LOCALAPPDATA% (next time you start the debug session, it will be rewritten).
We have also added support for advanced directory synchronization options in the upcoming v5.4 Beta 1. It allows defining arbitrary per-project or per-host directory pairs, setting advanced triggers for synchronization and allows transferring only changed files for both incoming and outgoing transfers. We are currently running the final tests on it and are expecting to release it in a few more days. Please consider waiting until we release it, as it might considerably simplify your setup.
Hi,
No problem. In case anyone else is searching for this, you can specify the “-j” argument via VisualGDB Project Properties -> Build Settings.
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.
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
Hi,
No problem and thanks for the kind words. Please try the build posted in this thread.
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.
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.
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.
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.
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.
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.
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/
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.
