Forum Replies Created
-
Posts
-
Sorry, it’s hard to suggest anything specific without knowing more details (how exactly is the target declared, what is the current directory with the header file and exactly is is spelled in the Makefile, what exactly gets edited in the CMakeLists.txt file).
One possible cause for this would be CMakeLists.txt using the regular /path/on/target syntax to specify include directories instead of ${CMAKE_SYSROOT}/path/on/target. The former syntax will only work when compiling directly, while the latter will work both when building on Linux and Windows.
VS properties for the target can be opened by right-clicking on the target (specific executable or library) in Solution Explorer and selecting “Properties”.
Edit: the VisualGDB 5.5 development branch does automatically use the ${CMAKE_SYSROOT} syntax for automatically discovered directories (e.g. VisualGDB-5.5.1.3300.msi), however it hasn’t fully passed all our internal tests and may be less reliable than the stable v5.4 release.
Thanks, looks like this memory layout slightly changed the format of the output from objdump that was used by VisualGDB to gather disassembly data.
We have fixed it in the following build: VisualGDB-5.5.1.3299.msi
Sorry, this might be something set on the VS level. Please try running notepad.exe instead of the batch file (so that the build waits until you close Notepad).
Then use the Process Explorer to check the environment block of the Visual Studio itself (devenv.exe), launched Notepad instance and the MSBuild executables (msbuild.exe) if you are using MSBuild.
Let us know at which stage is the PATH reset and we might be able to suggest a workaround.
Thanks, it looks like the new STM32 Arduino package builds executables without debug information by default.
We have updated VisualGDB to automatically detect and fix this condition: VisualGDB-5.5.1.3298.msi (see the bar on top of the source files belonging to the Arduino project).
Hi,
Sorry, no news for STM8. STM32WB is already supported (see the following tutorials: https://visualgdb.com/w/tutorials/tag/stm32wb/).
No problem, it turned out our OpenOCD toolchain was using the old-style definition file that had hardcoded paths. We have updated both the toolchain and the OpenOCD repository so that they don’t have any paths hardcoded and will work out-of-the-box with arbitrary locations.
We have also fixed the “Debugging exited without any breakpoint hits” error (there was a glitch in one of the CMakeLists files, although it’s hard to say why it didn’t trigger with the old path/toolchain).
Let us know if you find the root cause of the serial number matching problem and we will be happy to update our OpenOCD package.
Sorry, we have tried reproducing this for the latest supported ESP-IDF version (4.0), but could not get the behavior shown in the video.
If you could confirm that the problem persists with ESP-IDF 4.0, please share the full repro steps from creating a project. If the problem is specific to ESP-IDF 4.1, please consider editing the configuration manually until ESP-IDF 4.1 reaches the “stable release” stage and is officially supported by VisualGDB.
Sorry, we are not aware of this issue. Please try checking if other variables get overridden as well (e.g. by running ‘set’ instead).
If this doesn’t help, please try creating the most basic repro project and share it with us so that we could try replicating this. That said, please also ensure the VS instance you are using doesn’t inherit some custom environment and that your environment block doesn’t exceed Windows limits.
Hi,
No problem, we have rechecked the latest EFM32 SDK (5.8.3) and updated the VisualGDB’s EFM32 BSP to match it.
Please update it via Tools->Manage VisualGDB Packages and you should be able to use the new devices.
No problem, please try this build: VisualGDB-5.5.1.3294.msi
We have added a context menu command “Set as Main Component” to the ESP-IDF component items in Solution Explorer for CMake projects. Flagging an arbitrary component as the “main” one will now merge its contents directly under the top-level item in Solution Explorer.
Hi,
Real-time variables are included in the Custom edition of VisualGDB and higher. If you are using a lower edition, you can upgrade it here: http://visualgdb.com/buy/
If you are using VisualGDB Custom, please share a screenshot of the Help->About VisualGDB window and a screenshot of the Visual Studio window with the Debug->Windows menu open and the VisualGDB-based items missing and we will help you get them to appear.
Sorry, we have researched the complexity of supporting custom boards with Analyzer2Go and created a detailed checklist and plan, however due to other feature requests received for other products, we are currently not able to allocate any time for this in the nearest time frame and will have to wait until the Analyzer2Go user base grows more before proceeding with this feature, sorry.
Sorry, we have tried reproducing the issue on a clean machine, but could not get anything to fail
The problem might be caused by a conflict with some other package versions installed somewhere else (see the directories listed in the build command line, such as C:\Program Files (x86)\Arduino/hardware).
Please try the following steps to resolve this:
- Try clearing the Tools->VisualGDB->Arduino->Arduino IDE Directory setting.
- Try clearing any other directories mentioned in the build command line.
- Confirm that the problem exists for a freshly created demo project and is not specific to one pre-existing project, that could be referencing some libraries incorrectly.
If nothing helps, please try running the build from the Arduino IDE under Process Monitor and enable filters for “Process Create” event. It will show the command line used by the Arduino IDE to launch arduino-builder (you would need to locate the instance that has -compile among the arguments). The differences in the build results are likely triggered by the differences in command lines (e.g. the Arduino IDE passes some paths in a different order).
Please try comparing the command lines and then adjusting the VisualGDB’s command line to match the one captured from Arduino IDE and running it manually via Command Prompt. If you can find a specific argument, or argument sequence that triggers the problem, we should be able to update VisualGDB to avoid it and produce the same results as Arduino IDE does.
Hi,
Please ensure you are using the Advanced CMake Project Subsystem. Then you will be able to use the automatic header discovery to fix the project settings automatically.
If you prefer to configure everything by hand, you would need to find the target (i.e. an library or an executable) that contains the faulty source file and add the directory containing the source file to its include directories under VS properties for that target.
If you still cannot find the corresponding settings, please let us know your project type (Advanced CMake/Regular CMake) and we will provide more detailed instructions.
No worries. Unlike the stable v5.4 release, the development branch of VisualGDB (v5.5) is indeed less stable, some of new/changed functionality has been fully tested yet. That said, as long as we receive sufficient details in order to pinpoint/reproduce the issues, we are usually able to release fixes relatively fast.
