[support]

Hi,

The VisualGDB SSH connections are stored in .sshconnection files in %APPDATA%\VisualGDB\SSHConnections. Could you check that the directory exists and is writable under your current user account?

[support]

The environment variables will only be picked up if you are using Clang IntelliSense. Are you using the default VS one?

[support]

Hi,

Sorry, we assumed that you have already converted the Makefile to work with Linux. If you only have a Windows NMake project, please try creating a Linux configuration for it by following this tutorial: http://visualgdb.com/tutorials/porting/linux/

[support]

Hi,

We have tried opening your project and could not reproduce the error. So it must be caused by something else (opening it from command line or some global setting you are using). We would be happy to pinpoint and resolve this, but we would need to know more about the circumstances of the error. It would definitely help us if you could try starting an empty VS instance and opening the project via File->Open->Project/Solution and let us know if the problem still persists.

[support]

Hi,

Thanks for contacting us. This is indeed a bug of VisualGDB – it shows the uint8_t values as signed instead of unsigned. We have fixed this in the upcoming VisualGDB 5.2 Preview 2. Sorry about the inconvenience.

[support]

Hi,

Unfortunately we have not heard from them. We’ve sent another ping today.

[support]

Hi,

Yes, if your embedded profile contains the <BSPSubdirectory> element (e.g. set to just “BSP”), the relative path for the peripheral register definition will be evaluated against the $(ProjectDir)\BSP.

[support]

Hi,

This might be related to the VisualGDB/VisualKernel interoperation. Do you have both of them installed? If not, does running VS elevated solve the problem?

[support]

Hi,

The “Go to definition” should only take some time on the first use after major project changes so that VisualGDB can update its cache. Perhaps you are changing some common include files that cause the cache to be invalidated?

If not, could you please open the Clang IntelliSense Diagnostics Console, clear its output, then run the Go-To-Definition command and send us the diagnostic output that is generated when you run it?

[support]

This is a known bug. Please try this build and let us know if the problem still reoccurs: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.954.msi

[support]

Hi,

Currently not as it only affects the global settings (not per-project settings), so the change needs to be done only once. We will monitor the feedback on this and consider adding automatic settings conversion.

[support]

Hi,

VisualGDB 5.2 changed the internal settings engine to a new hierarchical one, so it will indeed not import some of the settings from the older version. However this will happen only once; after you change the settings again, VisualGDB 5.2 and all subsequent versions will use them.

Regarding the old projects, they got switched to Clang IntelliSense because the global “default engine” setting got reset to it. Please change it back via Tools->Options->VisualGDB and the projects will open under the VS IntelliSense again.

[support]

Hi,

The live watch/memory should work with OpenOCD and Segger J-Link. If you encounter any problems, feel free to let us know and we will help you solve them.

[support]

Hi,

Looks like VisualGDB is trying to link the original bootloader ELF file with the normal project. This should not happen with the latest VisualGDB 5.1r6. Either way, you can disable this by commenting out the following line in your main project’s Makefile:

LIBRARY_LDFLAGS += $(EXTERNAL_LIBS)

Note that the Makefile has several instances of this line for different project types.

[support]

Hi,

First of all, if you need to extend your trial, please simply contact our support via the contact form and they will give you a trial extension voucher.

Regarding the memory map, first of all can you try making a basic program that will turn some LED on to see whether the program ever gets executed correctly? If yes, the problem is related to debugging settings. If no, it’s related to compiling or linking.

You can indeed define the memory addresses for your code and data by creating a linker script file (you can search any of the VisualGDB BSPs for .lds files to get an example linker script) and then specify the path to it in VisualGDB Project Properties. The peripheral definition files are only used to visualize the peripheral registers and do not affect the functionality of your program.

You can also have a quick look at this tutorial if you have not done this already. It might explain some steps you could be missing.

[Author]

Posts