Forum Replies Created
-
Posts
-
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).
Hi,
Arduino would normally detect the libraries automatically based on the library directories. If this is not happening, please try narrowing the problem down to a specific library:
- Ensure that your .ino file includes the correct header file.
- Ensure that the library is located in one of the library directories (i.e. global per-user library folder, or a custom folder specified via VisualGDB Project Properties -> Arduino Library Directories).
If this doesn’t help, please try reproducing the problem with the same library on a freshly created project and share the exact steps from creating the project to observing library issues.
The “‘arduino:libraries’ is not found or not supported” error looks like TFS is trying to resolve a virtual path used by VisualGDB for the “Libraries” node in Solution Explorer. It should normally not cause any side effects and can be safely ignored.
It looks like VSS might expect some extra notifications from the Arduino projects. Please try narrowing it down to a specific sequence of actions that reliably triggers the problem and we will investigate it and try adding a workaround.
Sorry, currently the custom variables are indeed handled for each project separately.
We do have long-term plans for supporting property sheets that will allow sharing custom variable definitions between multiple projects.
As a workaround, please try using Windows environment variables instead. VisualGDB expands them same way as the project-level variables.
The link order to the object should not cause any issues because VisualGDB automatically uses the linker groups that instruct the linker to find symbols in every object inside the group.
Most likely, you have accidentally removed the implementation of HAL_SPI_Init() from your project. Please try searching all source files of the project for the “HAL_SPI_Init” text and ensure that the file implementing the function (i.e. providing a definition for it) is compiled and that the function implementation is not #ifdef-ed out.
You can read more about the differences between function declarations and definitions in the following tutorial: https://visualgdb.com/tutorials/tips/externc/
Thanks for the log file, it looks like our bug. We have fixed the problem in the following build: VisualGDB-5.4.108.3212.msi
