Forum Replies Created
-
Posts
-
No problem. BTW, the “bin” prefix should normally be discarded automatically. Feel free to share your CodeModel.json file and we will update VisualGDB to compute the target ID fully automatically.
Hi,
No problem, we will clarify. This update simply adds a list of pre-defined keywords like static_cast to the suggestion lists shown by VisualGDB. Pressing ctrl-space inside static_cast<> will still show preprocessor macros, typedefs, classes and many other object types. You can limit the display to a specific type using the filter buttons at the bottom of the suggestion list.
No problem, we have fixed it in this build: VisualGDB-5.4.104.3059.msi
Hi,
Please try setting the PYTHONPATH variable to point to the directory on the board where the Python scripts are uploaded. You can set it via VisualGDB Project Properties ->Debug Settings -> Common Settings -> Debug Mode -> Additional Environment. This should ensure Python can find import all the necessary modules.
Thanks for the log file. It looks like the Python debugging is not working because the variables used by VisualGDB to analyze the Python context got optimized away.
Please follow the instructions in this tutorial to build a modified Python executable that will have the necessary variables available.
No problem, we can help you get it to work.
First of all, please ensure you have the OpenOCD package installed (you can use Tools->VisualGDB->Manage VisualGDB Packages to double-check).
Then check the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\edp.xml file.
The GNUTargetFilter element defines the toolchains that are considered compatible with this package:<GNUTargetFilter>^arm-.*</GNUTargetFilter>
For Arduino projects, the GNU target is automatically derived from the name of the gcc executable reported by the Arduino build logic. E.g. for arm-none-eabi-gcc.exe it would be arm-none-eabi. You can find out the GCC path by checking the CodeModel.json file inside the build directory of your project. Simply updating the GNUTargetFilter in edp.xml to match it and re-opening the VisualGDB Package Manager to have VisualGDB reload the package definitions should get it to work. If not, please let us know the gcc executable name reported via CodeModel.json and we will investigate this further.
OK, we have added a setting for this: Tools->Options->Text Editor->C/C++ (VisualGDB)->Advanced->Code Completion->Additional suggested C++ keywords.
Please try this build: VisualGDB-5.4.104.3057.msi
Sorry, there is no other place other than the .mak files in the project’s directory where ADDITIONAL_MAKE_FILES would be set.
If you are still getting strange errors, please try creating another project from scratch – it should rule out any accidental Makefile modifications that could be causing this.
No problem, please try this build: VisualGDB-5.4.104.3057.msi
We have added an option under VisualGDB Project Properties -> Arduino to ignore the default library paths.
Thanks for sending us the repro project. We have fixed the issue in this build: VisualGDB-5.4.104.3057.msi
Good to know it works. As OpenOCD is a separate open-source tool that is independent from the regular ST-Link tool, this makes sense. That said, aside from occasional issues with the STM32L4 FLASH driver, OpenOCD is pretty reliable and usable.
The TestFramework.mak file would normally only be referenced when creating unit test projects, or referencing unit test frameworks. Either way, please try searching the Makefile and *.mak files for the “TestFramework” text and remove any references you find. If nothing helps, simply re-creating the project from scratch should solve the problem.
Hi,
Please use VisualGDB Project Properties -> Unit Tests page to remove the dependency to the test framework.
