Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
We did test that (made the temporary directory unwritable, then changed some settings, clicked ‘apply’ and then ‘cancel’ when VisualGDB complained about the directory). The settings were saved properly.
Perhaps the problem you are observing only affects some specific settings? Could you provide a more detailed description:
- What setting are you modifying
- When exactly do you cancel the test
- What do you expect to be changed
- How do you verify that it’s not changed
This should help us reproduce the problem on our side.
support
KeymasterHi,
The live variables are normally stored in the .vgdbsettings.user files. Perhaps your file is not writable and VisualGDB cannot update it properly? Either way, you can delete the file to reset all per-user settings like live variables.
support
KeymasterHi,
If you are using the Clang IntelliSense engine, VisualGDB actually provides its own navigation bar that is better than the VS one. If you don’t want to use it, simply disable the Clang IntelliSense via Tools->Options->VisualGDB->General and Visual Assist will taker over. Note that Visual Assist is not as good with GCC-specific header files as VisualGDB IntelliSense is.
support
KeymasterHi,
Thanks for sharing this!
support
KeymasterHi,
VisualGDB 5.x should still save the settings if you cancel the toolchain test. If it doesn’t could you let us know the exact repro steps? Perhaps some specific setting it not saved?
Regarding the temporary directory, you can actually change it for each host individuall via Tools->SSH Connection Manager->Host-wide settings. E.g. you can create a writable directory under your home directory and choose it.
April 11, 2016 at 17:05 in reply to: [QuickDebug] Source autodownload fails when using custom SSH port #7940support
KeymasterHi,
No problem. If you encounter further problems, don’t hesitate to start another thread.
April 11, 2016 at 04:53 in reply to: [QuickDebug] Source autodownload fails when using custom SSH port #7935support
KeymasterHi,
Thanks for reporting this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.1.4.674.msi
support
KeymasterHi,
Sure, you can do that easily with our VisualGDB product. We have a very detailed tutorial available here: http://visualgdb.com/tutorials/esp8266/openocd/
support
KeymasterHi,
It’s hard to say what could be wrong without seeing the hardware. Have you copied SystemClock_Config() from a proper example for your board? This function varies slightly between different boards.
If yes, we would need to first get debugging to work before we could give any further advice. Could you attach the full gdb log and the OpenOCD output so that we could see why the debugging is impossible?
support
KeymasterThe source files need to be physically added to the Solution Explorer. You can add them either one-by-one or altogether via right-click->Add->Import Directory Recursively.
support
KeymasterHi,
Good to know it works now. BTW, we have recently released a new toolchain with an updated gdb that should be a bit more stable.
April 8, 2016 at 03:14 in reply to: Sharing *.vgdbsettings between projects, inheriting path from *.vsprops #7921support
KeymasterCool. Thanks for sharing this.
support
KeymasterHi,
We could easily add variables like $(BuildUserName) and $(BuildHostName) and similar ones for deployment machine. Would that be helpful?
support
KeymasterHi,
The problem with raw telnet is that it does not support easy file transfer and has no convenient API for running just one command and seeing when it exited. It could be achieved via various workarounds, but they won’t be very reliable.
We currently recommend setting up a custom project and simply adding custom pre-debug commands to transfer your files to the device. Similarly, you can use the expect tool to connect to the target via raw telnet and specify it as the local GDB executable so that VisualGDB will simply launch it and send the commands there.
We will monitor the demand for this feature and consider adding it if the demand grows. In the meanwhile, feel free to try the workaround described above and if it does not work, we will gladly provide more detailed steps.
support
KeymasterHi,
You can easily remove all extra files from the project by unreferencing the HAL library in VisualGDB Project Properties -> Embedded Frameworks.
-
AuthorPosts