Forum Replies Created
-
Posts
-
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.
Hi,
Sorry, unfortunately the only case where the freeze/resume thread command is currently supported is kernel-mode debugging of multi-core devices via JTAG with VisualKernel where VisualKernel is fully controlling the status of each core. It is not supported for other debug sessions because the underlying gdb debugger does not support this functionality.
If gdb is extended in the future to support freezing/resuming of individual threads, we will add this functionality to VisualGDB as well.
It looks like something prevents Visual Studio from saving the solution file.
Please double-check that the solution is created and that the .sln file is writable and not open in any other application.
If this doesn’t help, please try creating another project/solution and check if the problem reoccurs. If not, please try comparing the working project to a non-working one (e.g. check whether placing the solution in a specific directory, or checking it into source control starts triggering the issue).
