[support]

Hi,

According to the log, it looks like the program exits with an error code. Please try checking whether it prints any error messages (in the “gdbserver” part of the log), like “cannot open display” or “cannot load library”.

[support]

Hi,

You can do that by opening Debug->Windows->Visual Watch (not Live Variables), adding “Foo” to the visual watch list, right-clicking on it and selecting “export data”.

[support]

Hi,

This may happen because the default implementation of printf() in the newlib-nano library does not support floating-point numbers. Please try explicitly switching to the “newlib-nano with floating-point support” via VisualGDB Project Properties.

[support]

Hi,

We have thoroughly tested VS2017 with VisualGDB and aside from the crashes that happen when importing large projects (confirmed by MS, fix scheduled in VS15.3), it works. Feel free to share the details of the errors you get and we will help you resolve them.

[support]

Hi,

As Clang is not widely used for embedded targets yet, any custom build we would make would likely trigger lots of bugs that are not otherwise triggered with regular Clang targets. Hence you can try building it from sources at your own risk (VisualGDB should recognize it as a proper toolchain), however we won’t officially support it until it becomes more popular.

[support]

Hi,

Just to clarify: does this happen when building, or is it an IntelliSense-only issue? In the latter case, please try opening VisualGDB Project Properties and regenerating MSBuild-related files on the MSBuild Settings page (if you are using MSBuild).

[support]

Hi,

One big cause of tricky problems could be this one:

warning : Found a source file with spaces in the path: “C:\Users\Raivis-STROPS\Desktop\power board kods\Power_board_V1.7\..\..\..\..\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32F0xxxx\StartupFiles\startup_stm32f030xc.c”.

GNU Make really doesn’t support paths with spaces, so this may cause very strange bugs. Other than that, please try opening VisualGDB Project Properties and changing the MCU type back and forth. This should force VisualGDB to regenerate the relevant parts of the project.

• This reply was modified 8 years, 6 months ago by support.

[support]

Hi,

You are welcome. It is a part of the VisualGDB design philosophy to allow tweaking and customizing the parts that may not work out-of-the-box, so that our users could get convenient experience even for rare scenarios that we don’t support directly. Our AVR support package is also open-source, so feel free to check it as a reference if you decide to customize further features.

You are also welcome to post any issues you encounter here and although we don’t guarantee seamless out-of-the-box operation for AVR devices, we should be able to suggest reasonable workarounds.

[support]

Hi,

Thanks for clarifying this. Just to confirm, you are not looking into exporting historical data, but rather a contents of a large array, right?

[support]

Hi,

Sorry for the confusion, we will try to clarify.

Visual Studio views the non-MSBuild VisualGDB projects as NMake projects (Visual Studio itself does not know the details about GNU Make vs CMake vs QMake and simply invokes VisualGDB to do the build). In order for those projects to work correctly, their VS-level settings should be configured as shown below:

If the ‘output’ is not set to a .vgdbsettings file, VisualGDB won’t treat this project as its own project and won’t show the settings command. If you manually manipulate the VS project configurations via the VS GUI, you could accidentally break those settings, causing VisualGDB to stop treating the project as a VisualGDB-based project.

Normally if you hold ‘Shift’ while right-clicking on the project, VisualGDB will show its context menu command and try to load the settings from the default file path (<project>-<configuration>.vgdbsettings). If the corresponding .vgdbsettings file is missing, VisualGDB will show default project settings that won’t reflect any of your project’s customizations. Hence the easiest way to check if the .vgdbsettings file is still valid and readable is to open the VisualGDB Project Properties while holding ‘shift’ and check that the settings look correct (e.g. the project type is set to the type you are using and not the default “Windows project”).

[support]

Hi,

Thanks for the suggestion, we have added a new setting for ignored extensions in the upcoming v5.3 build that defaults to .cpp, .c, .cxx and .cc files.

[support]

Hi,

VisualGDB normally does this automatically. Simply ensure that the softdevice is selected via your project properties and it will link it into your project.

[support]

Hi,

Just to double-check, are you using the latest esp32-gcc5.2.0.exe toolchain? A recent update to the ESP-IDF was interfering with the FLASH programming and it was only fixed in the 5.2.0 toolchain.

[support]

Hi,

The _estack message can be safely ignored. It refers to a mechanism that automatically checks for incorrect end-of-stack setting on ARM devices, however it does not work on ESP8266/ESP32 due to a different linker script layout.

[support]

Hi,

No problem, let us know if you run into any further issues with “program without debugging”.

With the popularity, yes, AVaRICE is much less popular than tools like OpenOCD. Arduino is indeed very popular, but it does not support low-level debugging and based on the feedback we got, most Arduino users expect the development tools to be free and there would not be much interest for a professional-grade tool like VisualGDB.

[Author]

Posts