Forum Replies Created
-
Posts
-
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.
No problem and good to know it works.
Our system usually recognizes most reinstallation scenarios and provides temporary activation credit, however as you had previously tried to activate the same 1-seat key on multiple seats, you had used up all temporary credit our system could give.
Thanks for confirming this. We have just retested VisualGDB with WSL on Windows 10 build 1903, however we could not reproduce the issue you described.
Please try running this build: VisualGDB-5.4.106.3193.msi
Then enable the VisualGDB Diagnostics Console, reproduce the problem and check the diagnostic output for the command line used by build the app launcher (search for LinuxAppLauncher.c). Then try running the command line manually and see if GCC reports any errors. Once you pinpoint a specific error, please let us know and we will try to add a workaround for this.
