Forum Replies Created
-
Posts
-
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
Hi,
Sorry, Python debugging on Raspberry Pi is currently broken. We are investigating this and will post an update here once a hotfix is available (please allow 1-2 working days for that).
Hi,
Thanks for pointing this out. It looks like a potential bug in our debug plugin. Would you mind sharing the address you used to load the configuration file? VisualGDB uses the addresses from this page, i.e. 2MB should load it at 0x1fc000.
