[support]

How often does this happen? We have encountered similar behavior on some versions of MacOS and it looked like a bug in their end of SSH. Could you build newer GDB from sources in your home directory and let VisualGDB use it explicitly?

[support]

Thanks for reporting this. We have fixed it in Beta 3.

[support]

Hi,

Thanks for your explanations. We have fixed it in Beta 3. We have also added an option (Tools->Options->VisualGDB->General) to override the default file masks used when creating projects.

[support]

Hi,

Thanks for reporting this. Could you please let us know how what exactly you are doing to browse the folder? Please feel free to attach a screenshot or a step-by-step description.

[support]

Hi,

First starting the app and then attaching to it is the default behavior of the Android debugger.
You can override it by selecting Android->Debug Options->Debug App Startup in Visual Studio.
Once you select that option, starting debugging will take slightly longer, but all your initialization breakpoints will be hit.

[support]

Hi,

Thanks for reporting this. Please feel free to report further bugs on this forum or simply send emails to support.
There was indeed a bug on our side. The build/debug customization pages were intended to appear in Custom and Ultimate editions only and activating them in other editions crashed the dialog as the underlying logic was not present.
We have updated the installer.

[support]

Hi,

Thanks for reporting this. We could not reproduce it on our side. Could you please send us your .vgdbsettings file so that we can diagnose this further?

[support]

Hi,

Thanks for reporting this. The project settings from the previous versions of VisualGDB are saved to the -.old file. Simply change the extension back to .vgdbsettings to restore it.

[support]

Hi,

Unfortunately this is not possible in the currently available release, however it will be significantly improved in the upcoming release.
The beta is scheduled to be released within a month from now.

[support]

Hi,

Currently the /rebuild command simply executes a clean sequence followed by the build sequence.
You can safely ignore the warning message after replacing the build commands. As long as you keep the “primary output” point to the .vgdbsettings file all VisualGDB functionality will work.

[support]

Hi,

Yes, VisualGDB expects the single-threaded output as it’s the only way to detect the full path of files (so that Visual Studio can show them) when GCC reports the relative path. If this is not a problem for you, you can safely ignore those warnings.

[support]

Hi,

You can run GDB manually (msp430-gdb.exe ) and run the following commands to program it:
target remote :
load

You can automate it using a script. Alternatively you can change the makefile to produce Intel HEX file instead of a binary file. Look for the line that calls objcopy and change it so that it produces Intel HEX format instead of bin. Run msp430-objcopy.exe –help to get more information about supported formats.

[support]

Hi,

This still looks like an incompatibility between your programmer and the msp430.dll. It is a known issue for Olimex devices (e.g. see https://forum.sparkfun.com/viewtopic.php?t=13349).
Please try copying ALL dlls from the Olimex directory (also hil.dll) into the msp430 bin directory. If this does not help, please also contact Olimex support asking whether your programmer supports debugging at all and whether it needs a firmware update. Please also inquire whether they provide a GDB server.

The download errors can be caused by various factors (e.g. what is the size of the BIN file?) but should not be related to the “Device not found” bug as device detection happens before downloading the firmware.

[support]

Hi,

Thanks for the suggestions, we have added them to our feature plan. For now you can use the following workarounds:
1. To disable an action from a command list you can press the “Copy” button, paste it into a text editor (it will be pasted as XML) and delete it. To get it back simply copy the XML definition back to clipboard and use the “Paste” button.
2. Try using Visual Studio macros to script commonly used commands. You can execute VisualGDB.exe /build file.vgdbsettings to let it run build commands from a given .vgdbsettings file.

We will share a link to the pre-release build in a couple of weeks, but please note that the .vgdbsettings file format has changed significantly and your files will be upgraded when you edit them with the new VisualGDB. To be able to use them with the old version, you will need to backup them.

As for the environment variables in the SSH manager, they may not work out of the box. Please let us know what you are trying to achieve so that we can provide a solution.

[support]

Hi,

A bit of clarification regarding the file transfer. VisualGDB actually maintains a local source cache as well. After transferring the source files it remembers the file names and their modification times in VisualGDBCache–SourceCache.dat and uses it during subsequent builds to determine which files have changed. VisualGDB uses the .Net BinaryFormatter to maintain the cache file, so normally it takes less than a seconds to update the cache. Note that VisualGDB does this for all files in the directory specified in the project settings. You could reduce the time greatly by specifying your working subdirectory instead of the root project directory. Alternatively you could setup shared folders (see this tutorial: http://visualgdb.com/tutorials/linux/ImageMagick/) to avoid file transfers completely.

Having an option to skip build command if no source files have been changed is a good suggestion, we will add this to the upcoming release.

Regarding the custom variables, you can currently use the environment variables to do per-user tweaking and refer to those as $(VariableName) in your VisualGDB settings. We have also added a much better support for configurable per-user variables in the upcoming release based on the feedback from other customers (supporting host names, user names, etc), however this will be a major release redefining the usability of GCC settings editing, so it will take 1-2 months before it is out. We could also provide you with a pre-release build once it reaches the point when it passes our standard test scenarios 🙂

P.S. If you are dealing with huge projects with custom types and have C# knowledge, you may be interested in our type visualizer SDK that can be used to let VisualGDB display arbitrary user-defined types in a readable way. You can find out more about it in this tutorial: http://visualgdb.com/SDK/tutorials/SimpleArrayVisualizer/

[Author]

Posts