Forum Replies Created
-
Posts
-
Hi,
Good to know it works. BTW, you can find out more about the expected project structure for esp-idf-based projects here: http://esp-idf.readthedocs.io/en/latest/api-guides/build-system.html
VisualGDB automatically follows it when creating new projects and cloning samples, but imported 3rd-party project may need adjustment. That said, you can also use the automatic header discovery logic to simply edit the component properties to let it use any include directories you prefer.
Hi,
Looks like the wiringPi library was either not built/installed successfully, or the toolchain synchronization after it was built did not complete.
Could you confirm that the “build” command for wiringPi succeeded and that the libwiringPi.so file is present in /usr/lib on your Raspberry Pi and in the corresponding directory inside the toolchain’s sysroot.
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2335.msi
We have added a context menu command to the coverage report viewer to hide files from a given directory (and a corresponding option to the Code Coverage page of VisualGDB Project Properties).
With gcov files, they are created per translation unit, not per source file, so VisualGDB will automatically locate all the relevant files and build a searchable report from them.
Hi,
No problem, thanks for reporting this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2334.msi
Hi,
Stepping through code on Nordic devices could be tricky due to the built-in watchdog that would reset the CPU each time it is stopped for a non-trivial amount of time, although it should not lead to the behavior you are describing.
From a quick look at the log file you attached, it looks that the Segger gdb stub fails to read the CPU registers shortly after the reset command:
Received monitor command: reset Resetting target Connected to 127.0.0.1 Read 2 bytes @ address 0x000003B4 (Data = 0xF107) Read 2 bytes @ address 0x000003E2 (Data = 0x1D3B) Read 4 bytes @ address 0x2000DFFC (Data = 0x4B642F0A) Downloading 4 bytes @ address 0x2000DFFC Reading all registers ERROR: Can not read register 0 (R0) while CPU is running ERROR: Can not read register 1 (R1) while CPU is running ERROR: Can not read register 2 (R2) while CPU is running ERROR: Can not read register 3 (R3) while CPU is running
This might affect the initial breakpoints or could cause other weird behavior.
Please try updating the Segger J-Link software and/or try adding delays (e.g. mon sleep 1000) before and after the reset command under VisualGDB Project Properties -> Debug Settings -> Advanced Settings.
Hi,
You can use the /runtests switch of VisualGDB.exe (see this tutorial) to generate an XML file with test results, however we don’t support automatically exporting them to TFS yet. As a temporary workaround, please try converting the output into one of the existing formats (e.g. NUnit) and then using a standard TFS plugin for importing the converted file.
Hi,
Please try using VisualGDB 5.4 Preview 3 with the new advanced esp-idf project subsystem. It provides a much better development experience for ESP32 projects.
You can read more about the new ESP-IDF project subsystem in the following tutorial: https://visualgdb.com/tutorials/esp32/esp-idf/
Hi,
Some environment variables are defined differently for different user accounts (also once the process is started, its environment won’t be automatically updated once you change the Windows environment settings), so we would advise checking where the variables are defined and also confirming that the build agent process inherits them properly (e.g. by running “cmd /c echo %VARNAME%” as a part of the build).
If this doesn’t help, please give us an example of a variable that doesn’t get resolved (i.e. where is it defined and what value you are observing) and we will try to help you get it to work.
Hi,
This is by design. Changing anything on the Embedded Frameworks page will automatically regenerate the file list.
If you want to exclude some of the files, please set the “Excluded from Build” flag via VS project properties. The file will then be still referenced from the .vcxproj file, but VisualGDB won’t try to compile it anymore.
Hi,
Good to know it works. Running TFS as the regular user is indeed the officially supported way. This scenario is included in our internal tests, so it should normally work out-of-the-box without any friction.
Let us know if you encounter any further issues and we will be happy to help.
Hi,
Welcome to the VisualGDB forum. You can definitely use VisualGDB to develop IoT-like applications for Raspberry Pi. VisualGDB supports a wide variety of different build systems (Make, QMake, CMake and MSBuild), so you should be able to quickly import existing code and samples into it and start experimenting with them.
The main advantages of VisualGDB is the deep integration with the underlying GNU tools. It comes with a special IntelliSense engine optimized for Linux codebase, advanced debugging engine that is capable of detecting common debugger problems and a powerful custom action engine that lets you customize various steps of your build/debug process. We also integrate many advanced tools (e.g. static/dynamic code analysis, memory leak detection and profiling with Valgrind). You can get an overview of the main VisualGDB highlights here: https://visualgdb.com/?features=linux
You could also browse our Linux and Raspberry Pi tutorials to get a quick overview of the VisualGDB workflow: https://visualgdb.com/tutorials/
The main disadvantage is that VisualGDB only supports C, C++ and Python. If you are planning to use a different programming language, VisualGDB won’t be able to offer much help.
Hi,
This might be caused by corrupt VS package cache. Please try following the instructions on the following page: http://visualgdb.com/support/loadfail/
Please note that the instructions are for VisualGDB; the only difference for VisualKernel would be the package name.
Hi,
The easiest way to fix this is to run Visual Studio manually on the TFS build server (from the same user account that is used by TFS) and create a new project using the VisualGDB project wizard (importing the toolchain if needed). This should ensure that VisualGDB can find all the necessary components and will automatically fix TFS-based builds.
If this is not possible, let us know and we will provide alternate steps on diagnosing why the toolchain is not detected.
Hi,
Most likely you have created an MSBuild-based project. In most of the cases this type of project is better than Make-based, although the steps for integrating a bootloader would be different (we don’t have a detailed tutorial for this yet). If you would like to follow the tutorial, please try selecting Makefile on the first page of the wizard instead.
Hi,
This is by design. The MSBuild-based projects must be build by invoking either devenv.exe, or msbuild.exe (VisualGDB would internally run msbuild.exe if you try building the .vgdbsettings file, but it looks like something is preventing it from finding the correct .vcxproj file in your case). Please try using the following command line:
msbuild.exe <.vcxproj file> /property:Platform=VisualGDB /property:Configuration=Debug
