Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
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.
February 9, 2018 at 19:08 in reply to: Setting location of coverage reports through command line #20023support
KeymasterHi,
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.
support
KeymasterHi,
Yes, please try running VisualGDB.exe /pkgmgr
support
KeymasterHi,
The ESP32 framework is very large and doesn’t work very well with GNU Make. Please try using MSBuild instead.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
February 9, 2018 at 06:26 in reply to: Setting location of coverage reports through command line #20011support
KeymasterHi,
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.
support
KeymasterHi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2051.msi
support
KeymasterHi,
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).
support
KeymasterHi,
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.
February 8, 2018 at 01:36 in reply to: Setting location of coverage reports through command line #19997support
KeymasterHi,
Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2048.msi
It will reuse the normal coverage report logic when launched from command line.
support
KeymasterHi,
Thanks for checking this. It is starting to look like the ESP8266 initialization data might have gotten corrupt. Please try setting the Debug Settings -> Additional FLASH resources to program -> Initialization Data file to <SysGCC>\esp8266\esp8266-bsp\RTOS-SDK\bin\esp_init_data_default.bin. This should force VisualGDB to program the initialization data as well.
If this doesn’t help, please try connecting to the COM port using a different baud rate and then resetting the board. The garbage after the “chksum 0xab” text might be a meaningful error message printed using a different baud rate, so connecting under that baud rate should show garbage instead of “checksum” messages followed by a meaningful error text.
support
KeymasterHi,
It looks like you are using an older VisualGDB build that does not support Android CMake projects. Please update to VisualGDB 5.3R8.
support
KeymasterHi,
It looks like a mismatch between the gdb stub baud rate in your project settings and the actual baud rate used by the device. Please try several typical baud rates (e.g. 115200, 74880, etc); if none of them works, please change your firmware to output the character ‘U’ (0x55 or 01010101, so it will look like a uniform clock signal) in a loop and use a logic analyzer to understand the actual baud rate (simply measure the period of the output signal). You can also try explicitly setting the UART period on your board before initializing the GDB stub.
support
KeymasterHi,
If you are using a VisualGDB-generated Makefile or an MSBuild-based project, simply add the sources of your library to Solution Explorer and adjust the missing include paths (VisualGDB will normally help you discover them and suggest adding them automatically).
Another option would be to import the entire project using our experimental mbed importer, although it may require changes to the open-source importer plugin, as the mbed internal structure keeps on changing between versions.
-
AuthorPosts