[support]

Hi,

Please locate the stm32f0xx_hal_conf.h file in one of the directories with the generated files and add it to the Include Directories field on the Makefile Settings page of VisualGDB Project Properties.

[support]

Hi,

We have fixed the problems related to the Find Symbol Results window in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.2.794.msi

It also contains numerous improvements to the IntelliSense engine that make it much faster for large projects.

You can resolve the stm32_compat.h problem by opening Visual Studio project properties (not VisualGDB Project Properties) and removing the stm32_compat.h file from the “Forced Includes” field.

Let us know if you encounter further problems.

[support]

Hi,

Indeed, you have probably missed the “Import a project -> Import a project built with other tools” option in the project wizard. As long as you select it, VisualGDB will create a project with a custom build system, but still import the source files you select. You can also import them later via right-clicking in the Solution Explorer and selecting “Add folder recursively”.

[support]

Hi,

You can use the system() function:

#include <stdlib.h>
int main()
{
    system("sudo apt-get upgrade");
    return 0;
}

Let us know if this works.

[support]

Hi,

Yes, please use the Clang IntelliSense engine. It is fully compatible with most of the Clang/GCC language extensions.

[support]

Hi,

Most likely, something gets broken with the build commands. Feel free to open another topic on that and we will provide troubleshooting advice.

[support]

Hi,

Sorry for the confusion. We did not mean custom steps, we meant changing the build subsystem from Make to Custom on the first page of VisualGDB Project Properties. This will replace the Makefile settings page with a Custom build settings page allowing more customization of the build/clean commands.

We add ‘clean’ to the default command in order to support cases when the default command passes extra variable values or command-line switches to GNU Make.

[support]

Hi,

Most of the ESP8266 memory is used by the library code from Espressif, so this is to be expected.

Regarding other problems:

1. Resetting the device will clear the breakpoints in the RAM. To re-enable them, simply click the “Break all” button in Visual Studio and then resume debugging as usual. If this does not help, please try adding forced breakpoints (asm(“break 1,1”)) in your initialization functions and checking that they get invoked after a reset.
2. What do you mean by “use UART with VisualGDB”? Connect to a COM port from VisualGDB so that you can see what your device is printing or are you taking about the UART functions of the ESP8266 SDK?

[support]

Hi,

The error simply means that your program’s code did not fit into the instruction RAM. Most likely enabling optimization has inlined some of the functions or unrolled some loops resulting in the size increase. You can try optimizing the code for minimal size with -Os instead of -O3. Alternatively you can use the Embedded Memory Explorer to see which exact functions contribute the most to RAM utilization.

[support]

Hi,

The error simply means that something in the build process failed without showing any error messages that VisualGDB could recognize. As suggested in the Errors list, please check the Output window for the details of the error.

[support]

Hi,

Most likely it is just a coincidence and the problem was fixed by re-downloading OpenOCD.

“Warn : unable to change server port after init” was definitely caused by our bug and we fixed it almost immediately after releasing the affected version. Most likely you have originally downloaded that version and then replaced it with a fixed one.

[support]

Hi,

We normally recommend using the Custom build system with custom makefiles. The purpose of the “GNU Make” system is to provide a user-friendly front-end for GNU Make for those users who don’t want to go deep into customizing Makefiles and just prefer setting things like CFLAGS via GUI and expect everything to work out-of-the-box. So we intentionally keep the settings there simpler than in the Custom build subsystem.

[support]

Hi,

This error means that the debug symbols for your module do not contain enough information to find the memory address of the requested variable. It can happen due to a variety of reasons:

• Incompatibility between your gcc and gdb versions
• Incompatibility between the debug information format (e.g. DWARF 4) and your gdb version
• Missing “-ggdb” in your compilation flags
• Symbols being stripped from the executable after it is built
• Symbols not matching the loaded executables

We would recommend setting up a “hello, world” project using the same build/debug machines, ensuring that it works and then comparing compiler flags and gdb versions with your actual project in order to find out what exact difference breaks the variable viewing.

[support]

Hi,

You can find that out by disabling multi-threaded build via VisualGDB Project Properties -> Make Settings -> Build Command -> remove the “-j<number of CPUs>”  (so that all files are compiled one-by-one) and checking the last build command (will look like arm-eabi-gcc -c <file.cpp> -o <file.o> …) in the build log before the error.

Then you can replace -c with -E and <file.o> with <file.E> and run the command manually. This will run the preprocessor on the input file and save the preprocessed output to a file named <file.E>. The preprocessed output will show what exact macros got expanded and which parts of the files got compiled or skipped.

If you are still not sure, please simply send us the single-threaded build log and the .E file so that we could suggest a solution.

[support]

Hi,

This is a known bug that was recently fixed. Please try re-downloading the OpenOCD debug package again and if this does not help, update to VisualGDB 5.1r6.

[Author]

Posts