Forum Replies Created
-
Posts
-
Hi,
The deactivation requests are handled on a case-by-case basis, but we do handle them even for licenses with expired support (please note that you will only be able to install the VisualGDB versions released within a year from your license purchase; we also advise making backups of all BSPs/toolchains/debug packages as the newer versions are not always compatible with older VisualGDB releases).
Hi,
OK, we have double-checked this and it looks like our programming plugin indeed did not load the init data file correctly in some cases. We have fixed it in the R14 toolchain relesae available here: http://gnutoolchains.com/esp8266/
You can program the FLASH memory without debugging via Debug->Program Firmware without Debugging.
Hi,
We have managed to reproduce the problem. VisualGDB was not properly copying coverage directory information to the test container file when building it outside Visual Studio.
We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2055.msi
If you encounter any further problems, feel free to contact us again.
Hi,
You can enable the .hex file generation via the Build Settings page of VisualGDB Project Properties (for GNU Make projects) or via the “Embedded Project” page of VS Project Properties (for MSBuild-based projects). Once enabled, the .hex file will be placed in the same directory as the .bin file.
Hi,
Strange, this should normally not happen. We can definitely investigate this if you could let us know the steps to reproduce it, or share the project files demonstrating the problem.
Hi,
The empty .job would normally mean that VisualGDB could not locate any raw coverage reports after running the project. This might be caused by some combination of settings that prevents VisualGDB from locating the files when running from command line.
Could you please check if you can reproduce this problem on a clean test project created via VisualGDB project wizard?
Hi,
Sorry, unit tests for Advanced CMake projects are not officially supported yet, so bugs like this one are to be expected. Either way, we can help you resolve this if you could attach the generated TestFramework.cmake file. Most likely CMake gets confused with some library references.
Hi,
As long as the KeepRawCoverageReports registry setting is set to 1, VisualGDB should keep the reports. Please try deleting the coverage report directory, running the tests via command line and let us know which exact files/directories were created. This should explain what is going on.
Hi,
The ESP32 framework is very large and doesn’t work very well with GNU Make. Please try using MSBuild instead.
Hi,
Most likely your program is missing some initialization code, or interrupt handlers. We would advise cloning a sample project for your board that demonstrates DMA, ensuring that it works, and then comparing the initialization code between the 2 projects.
Hi,
We are sorry about this. We have recently tested VisualGDB with the latest Android SDK and it managed to import the project as shown in our tutorial (you can simply copy-paste the SDK directory into VisualGDB Android Settings if the SDK Manager is missing from your installation).
If you encounter any further problems, please feel free to share the details and we will help you resolve them.
Hi,
All VisualGDB settings from Tools->Options->VisualGDB are stored in registry under HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings. If you are running VisualGDB on a machine without Visual Studio, we would advise simply exporting the settings from a regular machine via a .reg file and applying them on the second machine.
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2051.msi
