[support]

Hi,

OK, then please try modifying the .ui file and build the project. Do you see the “uic’ing <file name>” line? If not, please post the full paths to the .pro file and the .ui file here along with your FORMS = … line from the .pro file so that we could double-check those.

[support]

Hi,

Thanks for confirming this. In this case the best solution is indeed to ensure that the manual stack pointer assignment in the startup file gets compiled.

[support]

Hi,

You can already customize that via the External Memories page (requires custom edition).

Please refer to this tutorial for details: http://visualgdb.com/tutorials/arm/memories/

[support]

Hi,

Normally you don’t need to include the header files to the project. As long as you have the correct include directories in your project properties, both VisualGDB IntelliSense and the GCC compiler will locate the headers properly. The only reason why they are added normally is that you can easily locate them via Solution Explorer, but as long as you have them in another library, this should not be a problem.

Also if you are using the new MSBuild subsystem, you can add the HAL include directories to the ‘exported settings’ page of your library project and then they will be automatically added to every project that references that library.

[support]

Hi,

Thanks for the log file. It looks like after you run the ‘step over’ command, the main() function exits and the next stop is in the library code:

[   41648 ms] -stack-list-frames --thread 1
[   41653 ms] ^done,stack=[frame={level="0",addr="0x76874294",func="__libc_start_main",file="libc-start.c",fullname="/build/glibc-mqlSLF/glibc-2.19/csu/libc-start.c",line="321"},frame={level="1",addr="0x000162e8",func="_start"}]

Please try disabling optimization for your project to make stepping more transparent. This can also be a gdb bug related to stepping. In that case setting breakpoints and pressing F5 instead of stepping over the lines may help.

Regarding the verbose build logging, this depends on the internal structure of your project. Typically it is enabled by adding V=1, _V=1 or VERBOSE=1 to Make arguments, but it may be different in your case.

[support]

Hi,

The debugged executable should be stored in settings when importing projects (under Build Settings -> Main binary). If this does not happen, please let us know the exact steps to reproduce this so that we could help you.

[support]

Hi,

The “~/workspace/project” syntax is not supported by all Linux tools, so it won’t work properly. The “workspace/project” path is a relative path that can cause unpredictable behavior if specified as a project path. Please specify the full absolute path (i.e. /home/myself/worspace/project).

[support]

Hi,

Sorry about the confusion. We have only tested VisualKernel with JTAG on ARM. Regarding product capabilities, VisualKernel automates and simplifies the kernel debugging for configurations supported by the Linux kernel. The only exception is added support for debugging over Ethernet (KGDBoE), however it is not very reliable due to the limitations of the Linux Kernel.

[support]

Hi,

If you are using a remote build, please double-check that the file transfer settings for your projects include the directories with the .ui files and have *.ui specified in the masks.

If not, please check that the .pro file specifies proper paths to the .ui files:

FORMS     += MainWindow.ui

The paths should be relative to the directory with the .pro file.

[support]

Hi,

Thanks, we can certainly investigate this. Please let us know whether you get an error during the FLASH programming or it succeeds, but then the firmware fails to start?

If the programming succeeds, but the program does not start, please try reading the FLASH contents via esptool, then program the image via esptool and re-read the FLASH contents. Then please compare the FLASH contents after programming with VisualGDB and with esptool.py and let us know the difference.

If the programming fails, please attach a screenshot showing the error so that we could know where exactly it happens.

[support]

Hi,

This error happens because the newlib-nano does not include the default implementations for system calls like _sbrk().

To fix this, please simply enable the ‘provide default implementations for system calls’ checkbox on the first page of VisualGDB Project Properties.

[support]

Hi,

This is a tough one unfortunately. JTAG is widely used with ARM-based Linux boards, but is somewhat hard to find on x86/x64. We would recommend double-checking that with your hardware vendor.

[support]

Hi,

Unfortunately this is not possible directly. Selecting one of the build subsystems simply tells VisualGDB how to build the project, but it does not automatically add any special preprocessor macros to the project settings. So the only way to detect Qt out-of-the-box would be to check for macros that QMake itself defines.

Defining a macro like QT_PRESENCE via VisualGDB Project Settings is also a good workaround.

[support]

Hi,

Good to know it works.

The ‘custom’ build system is used for projects where VisualGDB does not control the Makefile structure and cannot do precisely aimed edits to it. This is always the case when you import an external project (as the Makefile was not generated by VisualGDB). The only practical difference is that you would need to synchronize IntelliSense settings manually and edit the Makefiles directly instead of the VisualGDB GUI.

When you switch to the regular GNU Make subsystem, VisualGDB regenerates the Makefile based on its own template and will know how to edit it based on the settings from GUI. Although this is easier to handle, it will replace any custom steps present in the original Makefile, so VisualGDB does not to this unless explicitly requested.

[support]

Hi,

It is hard to tell what is causing this without knowing more about your project structure. Looks like VisualGDB managed to upload 1 new file, but when Make was launched remotely, it did not find any changes. This could happen if your Makefile rules don’t properly reference the file you uploaded or if your upload settings exclude some files vital for building.

We would recommend enabling verbose output via Tools->Options->VisualGDB, checking which source file gets uploaded and then double-checking the Make rules to see that this file is listed as a dependency.

[Author]

Posts