[support]

Hi,

OK, please let us know what errors you are encountering so that we could help you.

[support]

Hi,

Thanks, we’ll consider adding an option for that in v5.2.

[support]

This is a known issue; VisualGDB does not deploy the shared libraries during toolchain testing. You can safely ignore the error. If you get it during debugging, please ensure that the project producing the libraspicam.so is referenced by the project you are debugging. Alternatively you can add a pre-debug action to deploy the .so file manually.

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

[Author]

Posts