Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
Looks like the Clang IntelliSense might be having troubles locating some header files. Are you using a Makefile-based project or an MSBuild-based one?
Does changing the MCU forth and back (so that VisualGDB regenerates all settings) resolve this?
support
KeymasterHi,
It’s hard to say what could be causing this without seeing further details. One cause could be the header directories. Regenerating the project settings (e.g. by changing the MCU forth and back) could resolve this.
If it does not help, please let us know the exact details of the errors you are getting and we will help you.
March 12, 2017 at 23:02 in reply to: STM32 UART Definitions not found for HAL but ok for StdPeriph? #10651support
KeymasterHi,
Our UART tutorial is indeed old and covers the older STM32 StdPeriph library. We will eventually add another version of it showing how to use the newer HAL library, but currently our best advice would be to look up the UART example for your board (select “use examples from STM32Cube” on the sample selection page of VisualGDB Project Wizard) and use the code from it.
March 12, 2017 at 22:19 in reply to: Compiler warnings from Keil toolchain incorrectly formatted #10648support
KeymasterHi,
Thanks for reporting this, looks like the updated BuildMessageRegexes.xml file contained a small error. We have updated the version linked from our tutorial. Let us know if it works.
support
KeymasterHi,
This error happens when VisualGDB tries to move the generated binary from the .data section to .rodata. Looks like the ESP32 objcopy tool has troubles parsing the ESP32 ELF files.
Similarly to the previous step, please try locating the .data2rodata.rsp file and experiment with the command line to find a setting that works.
support
KeymasterHi,
This sometimes happens when the target system has loops in symbolic links (e.g. /usr/include/subdir linked back to /usr/include, resulting in an infinite /usr/include/subdir/subdir/subdir/… loop). In most of the cases those errors can be safely ignored.
support
KeymasterHi,
You can try adding a new cross-compiler-based Linux configuration to an existing project as shown in this tutorial: https://visualgdb.com/tutorials/porting/linux/
support
KeymasterHi,
Please try selecting “reinstall” in the VisualGDB installer or simply uninstall VisualGDB and install it back. This should fix the integration issues.
support
KeymasterHi,
No problem, we help you pinpoint this and find a workaround. Could you please attach a screenshot of the IntelliSense errors you are getting so that we could check if they look like any of the known issues?
support
KeymasterHi,
We have been investigating this since the slow extension reporting was added in one of the VS preview builds and it looks like t might be caused by the “Start your trial” message shown by VisualGDB when you start VS. We will look into displaying the window when a VisualGDB project is opened instead.
If you believe something else is affecting the startup time, please check the View->Other Windows->VisualGDB Diagnostics Console window. The first line there should report the actual time it took VisualGDB to initialize.
support
KeymasterHi,
We have successfully run our internal integration tests on VS2017 and have also received feedback from our users indicating that the main functionality works. There are minor glitches (like VS showing the “VS2015” label for the old projects), but they don’t disrupt the workflow.
support
KeymasterHi,
OK, this means that the esp32 linker cannot convert the binary file to an ELF file (so that the linker could merge it into your project). Please try locating the <file>.bin2obj.rsp file in your build folder and running the xtensa-esp32-elf-ld.exe manually with the flags specified there. Then try experimenting with adding and removing flags to see if ESP32 requires some special options to make it work.
Once you get a combination of options that work, you can edit the %VISUALGDB_DIR%\MSBuild\Targets\binary.targets file to ensure VisualGDB always uses those options.
support
KeymasterHi,
It’s hard to say why the breakpoints would not work. ESP32 and ESP8266 is generally very unreliable and some other settings may be interfering with the breakpoints. Our best advice would be to try setting them in different locations and try to see what causes them to fail (e.g. code in RAM/FLASH or code executed during startup).
support
KeymasterHi,
Sorry, we have indeed not tested this explicitly with ESP32, so it may need some minor adjustments. Feel free to let us know the errors you encounter and we will suggest how to solve them.
support
KeymasterHi,
Thanks for the repro, we have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.15.1399.msi
-
AuthorPosts