Forum Replies Created
-
Posts
-
Hi,
We have just discovered your post in the “other tools” forum and moved it here. To get faster support for VisualGDB-related issues, please create topics in the VisualGDB forum.
Please follow our Tiva tutorial to create a Tiva project with VisualGDB.
Hi,
Last time we checked, the new toolchain was not compatible with any stable ESP-IDF releases (using both 3.2 and 3.3 results in build errors).
We do not advise using pre-release ESP-IDF checkouts due to relatively low reliability and hence will not officially release a toolchain based on one until it reaches a stable state.
If you would like to experiment with this at your own risk, we can help you configure VisualGDB to recognize the new toolchain, however you would need to renew your technical support first. Please also note that the new ESP-IDF/toolchain might be broken in some ways that would make debugging, or other functionality impossible and we cannot guarantee that it will work as expected.
Update: we confirm that the new toolchain works with the master ESP-IDF branch when imported into VisualGDB, however it only works when using GNU Make. CMake support is currently broken.Our previous advice regarding ESP-IDF branches still holds – please avoid using the pre-release branches unless you are prepared to troubleshoot complicated issues.
Hi,
This is actually a bug introduced by the new “Optimize rendering for screens with different pixel densities” setting in VS2019, that prevents the tool windows based on the WinForms technology from being shown correctly. We have added a workaround for this in the following build: VisualGDB-5.4.109.3224.msi
Please let us know if it doesn’t solve the problem.
The ESP-IDF framework is indeed very complicated and may not always work out-of-the-box. Generally, if you believe that a certain version of ESP-IDF doesn’t work at all, please request help on the ESP32 forum. On the other hand, if the framework works as expected (e.g. the project builds successfully via command line), but VisualGDB does not work together with it, we should be able to fix it as long as you are using an official ESP-IDF release and can provide sufficient details for us to reproduce the problem.
Yes, please send it to us via our support form.
Normally, unless you change a specific project-level setting (e.g. add another sketch file), the project itself doesn’t need to be checked out, so based on what you have described, this looks OK.
Hi,
Please try using the Debug-only preprocessor macros field on the first page of VisualGDB Project Properties (ensure you are using the latest VisualGDB version).
This is by design. The Arduino build system prioritizes simplicity over flexibility and hence automatically finds libraries by scanning the main header file for missing includes and then resolving them to the libraries.
Please let us know the email associated with your key (or update the forum profile accordingly) and we will let you know the latest VisualGDB version that can work with it.
This looks like something coming from the ESP-IDF subsystem itself, most likely an incompatibility between the ESP-IDF and the Arduino package.
Please follow our ESP-IDF Arduino tutorial to the letter, including the exact versions of the packages. The ESP-IDF subsystem is very fragile and may not work with other combinations of versions.
This might be something specific to a certain setup (e.g. Ninja/CMake or certain warning flags).
Please try reproducing the problem on a freshly created MinGW-based “Hello, World” project and attach the project here. If we could reproduce the problem on our side, we should be able to fix it, or suggest a workaround.
Sorry, those are known limitations of the Keil importer. It indeed only parses the primary target from the project file, and then creates both Debug and Release configurations from it. That said, you can easily create additional configurations via VisualGDB Project Properties and then adjust the preprocessor macros for each configuration separately.
VisualGDB does not include a special ARM simulator. It is compatible with the existing ones like Qemu, however that would require non-trivial setup on the Qemu side and we would generally advise against it unless you are prepared to edit Qemu source code resolving various issues.
The Keil Components are not yet imported by the project importer, but once you configure them, they should not be reset. If this happens, please try comparing the [platform name].xml file in the project directory with the last version that had the Keil Components working correctly. If you could share both files, we might be able to tell what is going on and suggest a workaround.
Hi,
Normally, VisualGDB should be already handling this automatically.
Please try checking the BuildMessages/GCCOtherMessage element in [VisualGDB directory]\Rules\RegularExpressions.xml file. It contains a regex that is used to find the ‘required from here’ lines in the output.
Please try applying this regex to the lines from your build log that don’t get mapped correctly to see why they are not matched and then try editing the regex to work around it (you may need to restart Visual Studio in order for the changes to take effect). Feel free to share the updated regex with us so that we will include it in our product builds.
Hi,
It looks like something about your target structure (names/locations of the targets) changes the default layout of the CMake-generated Makefiles and hence breaks the build command used by VisualGDB:
VisualGDB: Run “make libShared.so” in directory “/tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared” on dwstark@wilvm2 (SSH)
VisualGDB provides 2 workarounds for this:
- You can set the “Built all targets in a target’s subdirectory” flag under the regular VS properties (not VisualGDB Project Properties) for the CMake project (triangular CMake icon in Solution Explorer). This will change the build command from “make libShared.so” to just “make” in the target’s subdirectory. It will be less precise than building a specific target, but still faster than building the entire solution.
- You can try finding out the library’s target name inside the generated Makefile and set the “Advanced->Alternate Name for Building” setting under the VS properties for the library target (puzzle piece icon in Solution Explorer). This will replace the libShared.so part in the build command line.
Finally, please consider using Ninja instead of GNU Make (Ubuntu should have it available out-of-the-box). It results in faster builds and uses more predictable names for targets, eliminating the need to tweak the command line.
