Forum Replies Created
-
Posts
-
Hi,
Looks like your might be using Clang-format that is configured separately. We have just published a new documentation page explaining various IntelliSense and formatting engines and their settings: https://visualgdb.com/support/intellisense/. Please feel free to look through it and let us know if it still doesn’t help.
Hi,
Sorry, remote text search in Linux files is not yet supported. Search in all files works for projects that cache the files on the Windows machine (e.g. when you configure VisualGDB to upload files during build, or to use Windows/Linux shared folders). Projects using direct SSH access support IntelliSense-powered search (go-to-definition, find references, etc), but not the plain text search yet.
Hi,
It looks like you are again comparing a debug build make with VisualGDB against a release build made with Keil. Please make sure you compare equivalent builds.
It also looks like you have again selected the GCC compiler instead of the Keil compiler when importing the project. Please make sure you follow the instructions from our reply from February 3, 2020.
Hi,
Yes, please refer to the new searchable settings list page for details. Enter ‘Registers’ into the ‘Filter’ field to get the exact names/paths of the related settings.
Hi,
No problem, please try this build: VisualGDB-5.5.4.3525.msi
It uses the Command window font in the Raw Terminal as well.
Hi,
VisualGDB simply uses the regular CMake configuration names and passes them “as is” to the ESP-IDF build system. For details on how exactly ESP-IDF handles them, please check the ESP-IDF documentation, or use our CMake Debugger to step through the ESP-IDF’s CMakeLists files.
Hi,
If you believe the VisualGDB-based project is still working differently from the project built directly with Keil, please attach the updated projects (including the relevant AXF/ELF files) and we will help you compare them.
Good to know it works. Most likely, the breakpoints worked with a different configuration (e.g. when running gdb on the target where the paths would be different).
Either way, VisualGDB should normally show a warning about spaces in paths. If not, feel free to let us know more about how you created the project and we will double-check why the warning was not displayed.
Hi,
Please refer to the following tutorial (step 9) for the list of files that we recommend excluding from the source control: https://visualgdb.com/tutorials/arm/multiuser/
Sorry, our support only covers Sysprogs products. It is not possible for us to provide support for issues in 3rd-party tools and libraries, even if you are using VisualGDB to build them. Those libraries are not tested/maintained by us and hence are outside of our control.
No problem. Please try capturing a diagnostic gdb log as shown here. It should explain what is going on. If it doesn’t help, please attach the log here and we will help you get it to work.
Sorry, the only supported way to use the VisualGDB-generated Makefile is by building it from VisualGDB. Given the flexibility of GNU Make, you should be able to tweak it to work in other environments, but this is something to do at your own risk, since it involves too many parameters that are outside VisualGDB’s control.
Hi,
Please try this build: VisualGDB-5.5.3.3512.msi
It will display more informative error messages when navigation to build errors fails.
The “requires whitespace after the macro name” error is likely caused by inconsistent target-specific profile. Please try regenerating the MCU-specific part of the project via the first page of VisualGDB Project Properties.
