support

Forum Replies Created

Viewing 15 posts - 5,581 through 5,595 (of 7,899 total)
  • Author
    Posts
  • in reply to: Build: 0 errors; IntelliSense: 126 errors #10659
    support
    Keymaster

    Hi,

    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?

    in reply to: Intellisense stopped working #10658
    support
    Keymaster

    Hi,

    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.

    support
    Keymaster

    Hi,

    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.

    support
    Keymaster

    Hi,

    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.

    in reply to: ESP32 Custom Build Step #10646
    support
    Keymaster

    Hi,

    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.

    in reply to: UpdateSysroot can't complete: path too long #10645
    support
    Keymaster

    Hi,

    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.

    in reply to: Switching to cross compiling #10644
    support
    Keymaster

    Hi,

    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/

    in reply to: VisualGDB not seen in Visual Studio 2017 #10643
    support
    Keymaster

    Hi,

    Please try selecting “reinstall” in the VisualGDB installer or simply uninstall VisualGDB and install it back. This should fix the integration issues.

    in reply to: Build: 0 errors; IntelliSense: 126 errors #10637
    support
    Keymaster

    Hi,

    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?

    in reply to: Visual Studio 2017 RTW and VisualGDB 5.2r8 #10636
    support
    Keymaster

    Hi,

    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.

    in reply to: VS 2017 Released #10635
    support
    Keymaster

    Hi,

    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.

    in reply to: ESP32 Custom Build Step #10634
    support
    Keymaster

    Hi,

    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.

    in reply to: ESP32 Wrover kit JTAG #10631
    support
    Keymaster

    Hi,

    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).

    in reply to: ESP32 Custom Build Step #10630
    support
    Keymaster

    Hi,

    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.

    in reply to: VisualGDB Program Output: random blank lines #10618
    support
    Keymaster

    Hi,

    Thanks for the repro, we have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.15.1399.msi

Viewing 15 posts - 5,581 through 5,595 (of 7,899 total)