Forum Replies Created
-
Posts
-
Hi,
Thanks for renewing your license. The timing report on your screenshot does not mean that VisualGDB is running – instead it shows the timing of the last operation.
The error you are describing might be caused by unsupported encoding (Clang IntelliSense only supports UTF-8). Please double-check the encoding used to save the files and ensure they are saved as UTF-8.
Hi,
Please try disassembling the file by running arm-eabi-objdump -D [ELF file] > disasm.txt, then search for the address shown in the error message.
Hi,
If the project builds successfully from command line, please try importing it into VisualGDB using the import wizard and then compare the manual build command line against the command line issued by VisualGDB (you can find it in the View -> Output -> Build Output window). Once you identify the part of the command line that breaks the build, we can help you configure VisualGDB to ensure it uses the correct command line as well.
Hi,
Sorry, we cannot provide much help troubleshooting 3rd-party libraries and components as a part of our product support. Our best advice would be to try searching the codebase for the definitions of the missing symbol and ensuring that the corresponding source or library file (.a) is included in the project. You may also find this tutorial useful – it explains the difference between C++ declarations and definitions and shows some tricks for finding symbol definitions in object files.
Hi,
Good to know it works. If you encounter further issues, please don’t hesitate to get back to us and we will be happy to help.
Hi,
Unfortunately, it is impossible to narrow down the problem based on the limited description you provided. If you could reproduce the problem on a smaller project and attach it here, we should be able to investigate what is going on.
Hi,
Sorry, we are not sure what you meant. The project should normally import correctly as long as the original Keil project has the correct include paths.
Please try locating a specific header that is not being found and ensure that its location is listed in the Include Directories field in VisualGDB Project Properties.
Alternatively please try reproducing the problem on a smaller Keil project (that builds with Keil, but doesn’t build after being imported) and attach it here so that we could investigate.
Hi,
Sorry, we don’t have a tutorial specifically for GTK+. Please try following the generic Linux project import tutorial.
Hi,
Please try changing any settings on the Embedded Frameworks page to resolve the debugger_check problem.
In order to fix the REL32 problem, we would need to be able to reproduce the issue on our side (please check the function located at the address shown in the error and see if you can share the source code for that function or a simplified version of it that still reproduces the problem).
The last error looks like you are trying to validate stack usage without actually specifying the stack size. Please reference the “fixed stack/heap” framework to set the stack and heap sizes explicitly.
Hi,
Great to hear you found VisualGDB useful. There are indeed several ways to build VisualGDB projects on the build server without installing VisualGDB there.
Once way would be to create a CMake-based or Makefile-based project. For these type of projects the build is managed by the external Makefile (or CMakeLists.txt file) and hence they can be built by running Make/CMake manually.
If you would like to use MSBuild, please check the .rsp files generated in the build directory on your Windows machine. Each RSP file contains the exact command line used by VisualGDB to compile or link that file (VisualGDB would simply run <gcc executable> @<relative path to the RSP file> from the main source directory). You could then create a very basic script that will enumerate the rsp files and reconstruct the build script for the build server (you will need to replace the paths in the .rsp files via some basic pattern matching though).
Let us know if you have further questions and we will be happy to help.
Hi,
Thanks for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2784.msi
Hi,
Thanks for reporting this. We will investigate it and will release an updated BSP in the next week.
Hi,
You should be able to work around this by adding the directory with the ULP toolchain to the global system PATH or MinGW2’s .profile/.bashrc. Alternatively, please try this build and add the relative path of the directory with the ULP toolchain to the AdditionalPathDirs element inside toolchain.xml. VisualGDB will automatically add it to PATH when running the ESP-IDF tools.
Hi,
Sorry, not yet. It is still queued for investigation and we will probably get a more specific timeframe for it in the next 2-3 months.
Thanks for the update. Not sure what you meant about private and public-scope source files. CMake libraries typically have private and public header search paths and properties, but there should be just one list of source files. If you believe this is caused by some specific layout of your libraries, could you try reproducing it on a clean CMake project and send it to us? If we could reproduce the problem on our side, we should be able to fix it (or suggest a workaround).
If not, please use this build. It will show the path to the CodeModel.json file in View->Output->Advanced VisualGDB Projects Output (search the window contents for CodeModel.json).
The jumps inside Solution Explorer are handled by the VS itself. Visual Studio 2017 does not switch the active file automatically and provides a button for doing that instead. If this doesn’t work, please attach a screenshot of the entire VS window showing the problem (please don’t attach cropped screenshots – they hide the state of many common controls, project load status, etc. and generally make it nearly impossible to understand what is going on).
No worries about the editor. We have edited your post fixing the formatting.
