Forum Replies Created
-
Posts
-
No worries. BTW, as long as VisualGDB is fully initialized (either when you create/open a compatible project, or just run the Help->About VisualGDB command), the “import folder” command should appear for all .vcxproj projects, even if they are not based on VisualGDB.
Hi,
Please double-check that other VisualGDB commands are present and that the Import Folder command was not explicitly hidden via Tools->Customize.
If nothing helps, please share a screenshot of the About VisualGDB window from the same VS version, and also a screenshot of the entire screen showing Solution Explorer and the context menu where the “Import folder” command would normally appear, so that we could try to understand what is going on.
If Visual Studio lists VisualGDB under the extensions, but does not update the menus, most likely some VS cache is corrupt. Please try repairing the VS installation or completely reinstalling it if the repair doesn’t work.
The ESP-MDF is very new and it’s hard so say how popular it is going to be, and hence when will we add full out-of-the-box support.
We could add the full MDF integration early as a part of our paid consulting services – do the necessary research and document the exact steps needed to get certain functionality working with ESP-MDF and VisualGDB. If you are interested, please contact our sales with more details and we will get you a quote.
Please try using the following tool from Microsoft to fix the Windows Installer issues: https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Sorry, VisualGDB hasn’t been explicitly tested with ESP-MDF. If the MDF framework works together with ESP-IDF, you should be able to import an existing MDF-enabled project into VisualGDB and then use the regular VisualGDB GUI for building and debugging it.
Hi,
Most likely the DMA module is not enabled for your project via the STM32 HAL configuration file. Please try comparing the configuration file to a project that is successfully using DMA and ensure all the necessary definitions are present.
Hi,
This might be by design for some project types (e.g. Arduino or Mbed) that only support a fixed set of 2 configurations (Debug/Release).
If you could attach a .vgdbproj file that triggers this, we should be able to tell more.
Most likely, you have used another statement before that would define the libsqlite3-dev variable.
We have just published a tutorial explaining different uses of the target_link_libraries statement in detail: https://visualgdb.com/tutorials/linux/cmake/target_link_libraries/
Feel free to give it a try – it explains the inner workings of the CMake library logic in detail.
Thanks for the update. Indeed, the comment parsing for STM32 codebase would not recognize the @param tokens, however the bigger issue there is that the comments are located in the .cpp files, not .h files and hence locating them would involve a longer go-to-definition operation that is not performed when displaying comments or argument suggestions.
We will try to improve this in one of the upcoming VisualGDB releases.
No problem, we have made the message box optional in this build: VisualGDB-5.4.106.3194.msi
Unfortunately, the GDB stub warning is handled on a different level, so it’s harder to make it optional as well. As a workaround, please consider moving to advanced ESP8266 projects based on the new RTOS SDK 3.x. They use the same logic as ESP-IDF projects where the memory programming is handled by ESP-IDF and the confirmation is optional.
Hi,
VisualGDB already supports importing existing ESP-IDF projects via the “Import” mode of the ESP-IDF project wizard. Simply clone the github repository locally and import it to VisualGDB to be able to modify and debug it with VisualGDB (given that the AT firmware code does not disable the JTAG pins).
Thanks for the update. It looks like we should be able to support it once requested by a user with an active technical support.
Good to know you found the root cause.
As the issue is triggered by a relatively rare setting, we would only be able to support it if there is an easy way to extract the path mappings from the WSL configuration file and if it’s requested by a user with an active support period (sorry, we could not find any orders associated with your email).
The vagrant warning in the diagnostics console can be safely ignored – it comes from VisualGDB trying to locate virtual machines managed by the Vagrant tool and will indeed appear if you don’t have the tool installed.
