Forum Replies Created
-
Posts
-
Hi,
Most likely, some setting between the projects is different (e.g. different toolchain, different libc type).
VisualGDB actually provides a convenient mechanism for troubleshooting this exact type of problem – differential view in Memory Explorer. Please follow this tutorial and you should be able to track down the differences.
No problem, please try this build: VisualGDB-5.5.7.3671.msi. It resolves the issue with the linker script and startup files.
In order to fix the problem with include directories and the FatFs folder, we would need to examine your project file (.cproject and .project) and also see the list of all source files in the project directory (obtained by running dir /s /b > list.txt). You can post it here, or send it to our support form.
If the project structure is confidential, you can also simply build our STM32CubeIDE project importer from source and adjust it on your side.
Hi,
VisualGDB does not use any special mechanism for Qt – it simply delegates the work to CMake, hence we do not have any special instructions for it.
Normally, CMake would pick it up automatically, as long as you resynchronize the sysroot via VisualGDB Project Properties -> Build Settings. If not, you may need to specify the CMAKE_PREFIX_PATH to point to the directory inside the toolchain where VisualGDB has copied the built Qt files.
You can set CMAKE_PREFIX_PATH via VisualGDB Project Properties -> CMake -> Extra Prefix Directories. If you are not sure about the exact value to set, please consider searching online for “qt cmake_prefix_path” for examples from Qt documentation and other discussions.
Hi,
Thanks for renewing your support. This might be indeed a bug in VisualGDB.
Please update to the latest VisualGDB 5.5 Preview 7. If this doesn’t fix the problem, please try creating a call stack of the crash as shown here and either post it here (along with the VisualGDB build number), or send it via our support form.
Hi,
Good to know it works. Generally, we advise relying on VisualGDB’s logic for installing the drivers, as we test it with many popular boards. Installing drivers manually always has a chance of breaking something accidentally.
Sorry, that would qualify as a technical support question and hence we would kindly ask you to renew your licenses, if you would like us to help resolving this.
If you do not wish to renew, please have a look through our documentation and tutorials. They may contain the answers to your questions.
Hi,
Based on the logs you attached, the exception is happening inside the VC++ project engine (Microsoft.VisualStudio.Project.VisualC.VCProjectEngine).
Most likely, Visual Studio has recently installed a minor update on both computers that started triggering the error. You can try reverting to the previous VS version and check if it resolves the problem, or alternatively report this to Microsoft support and see if they can fix it on their side.
Based on our experience, the ObjectDisposedException may occur sporadically inside the VC++ project engine, but reloading the solution while deleting the .vs folder often solves it. Either way, if you find this annoying, please consider using the Advanced CMake project subsystem (or other advanced project subsystems shown here). They are not based on the VC++ project type and won’t trigger this error.
Edit: If you suspect that the VisualGDB’s license checking logic is incorrect, we can temporarily extend the expiration date on your licenses in our system, and you can recheck if it changes anything.
Based on our experience, the pre-release ESP-IDF versions, such as v4.2, are extremely unreliable and can be difficult to configure. They also change the internal structure relatively often, so we do not support them until they reach the “release candidate” stage (see this page for a list of stable releases). You can try troubleshooting it at your own risk, but if it turns out not working, please follow the instructions from the second link we posted earlier to get to the latest stable version.
Hi,
Please see the following pages:
No problem. It looks like the mbed cache on your machine could be corrupt. Please try deleting the %USERPROFILE%\.mbed folder with all contents.
If it doesn’t help, please try opening View->Other Windows->VisualGDB Diagnostics Console, and then run the wizard. The diagnostics console will show the command used by VisualGDB to clone the mbed repository. Please try running it manually in the Command Prompt window and check if it works as expected.
If it doesn’t help, please let us know the command recovered from the Diagnostics Console, as well as the result of running it manually, and we will help you get it running.
Hi,
Most likely, the program you are trying to debug is built without debugging symbols, hence gdb cannot set any breakpoints.
Although we don’t have a MinGW-specific tutorial for this, we do have a very detailed one showing how this works on Linux: https://visualgdb.com/tutorials/linux/symbols/
OK, we have added out-of-the-box support for MaixDuino to VisualGDB. Please make sure you update to v5.5 Preview 7 and then follow this tutorial: https://visualgdb.com/tutorials/arduino/maixduino/
Hi,
This looks like a generic Raspberry Pi question and not something VisualGDB-specific.
Please consider posting it on Stack Overflow or Raspberry Pi forums instead.
Hi,
This looks like either a broken Python environment, or a 3rd-party tool (e.g. antivirus) is interfering with mbed.
Please try installing the latest VisualGDB 5.5 Preview. Then please try resetting your Python environment as shown here: https://visualgdb.com/support/mbedpython/
Hi,
Most likely, this happens because the project is referencing entire source directories instead of specific files, and we have not fully tested this case yet.
Please try this build: VisualGDB-5.5.6.3661.msi. It should be able to handle the directory-level references correctly.
