[support]

Hi,

We don’t do that because in many cases the machine with the previous VisualGDB installation is inaccessible. But we do respond quickly if you request an activation reset via our support channels.

[support]

Hi,

Please add the include paths via VisualGDB Project Properties -> Makefile Settings -> Include Directories.

This will configure both IntelliSense and your compiler correctly.

[support]

Hi,

Normally when you change something on the Makefile Settings page and click “Apply” VisualGDB should retest the settings and update IntelliSense. Did this not happen when you changed the toolchain? Does it retest correctly when you change, let’s say, CFLAGS?

We’ll add an option to select the language directly in the wizard in the next version of VisualGDB. We will also see if we can make the Program Output to be the default output after debugging.

[support]

Hi,

Could you try replacing the contents of the main source file with the following:

#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf(">%s<\n", getenv("LD_LIBRARY_PATH"));
}

Does it show the correct LD_LIBRARY_PATH when you debug it from VisualGDB?

[support]

Hi,

Yes, we have created the Clang-based IntelliSense because the VS IntelliSense does not work well with many GCC-specific extensions including the C++11 ones.

You can also enable the Clang IntelliSense globally via Tools->Options->VisualGDB. Please provide us an example of the code formatting problem in the other thread so that we could release a hotfix or suggest a workaround.

[support]

Hi,

The Clang IntelliSense includes formatting because switching the IntelliSense engine actually also disables the original formatting. Normally VisualGDB should import your VS settings and format your code accordingly. If it does not happen, we will certainly fix this. Could you give an example of a code formatted with our IntelliSense, with original IntelliSense and a screenshot of your VS indentation settings? This should allow us reproduce the problem and fix it.

[support]

Hi,

Please try changing the gdbserver port in VisualGDB Project Properties. Looks like the original port is already used by something else.

[support]

Hi,

The compiler uses a different path from linking. In fact, if you have specified relative paths to the libraries and not used the -L<directory> -l<library name>, the linker may hardcode the relative path in the executable leading to strange errors. We could help you fix this if you could share your linker command line, the exact LD_LIBRARY_PATH, the exact location of one of the libraries and the matching output from LDD.

[support]

Hi,

Can you confirm that the only missing registers are the second/third instances of some peripherals (e.g. TIMER1, TIMER2 are missing while TIMER0 is OK)? Looks like the Nordic SVD files are using an undocumented extension for those devices, so we should be able to update our SVD parser and fix this globally.

[support]

Hi,

Looks like there is some bug with stepping over instructions. We’ll follow up with Espressif on that and see if they could provide a solution.

Have you connected the nRST pin with J-Link? When we tested it with ESP8266, it did not start roughly 1 time out of 10, but worked 90% of the time. Please also try lowering the JTAG speed and experimenting with the “Reset mode” setting.

Regarding baud rates, this looks like a typo. The 115200 baud rate is the bootloader baud rate that indeed uses autobaud. Please also try changing the first one to 74880. We have updated the description and re-uploaded the toolchain. You can download the updated toolchain installer from http://gnutoolchains.com/esp8266.

[support]

Hi,

Normally specifying the path in LD_LIBRARY_PATH in VisualGDB Project Properties should solve the problem. If this does not work, please try setting it manually:

1. Connect to your Raspberry Pi via SmarTTY
2. Run ‘export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/pi/project/lib/arm’
3. Try running your executable
4. If it does not work, run ‘ldd <executable name>’ and check for messages about missing libraries

Most likely you are missing some other dependencies (libraries required by other libraries) or have some invalid symlinks somewhere.

[support]

Hi,

You can simply replace your cross-compiler (or install it into a different directory and choose it from the wizard) and VisualGDB will show it as an option in the wizard. You can also retarget your existing projects to a different compiler via VisualGDB Project Properties -> Toolchain Settings.

Note that you can also download our pre-built Jessie image for Raspberry Pi that includes a newer GCC: http://gnutoolchains.com/raspberry/jessie/

[support]

Hi,

VisualGDB does that when you open a .h file or another file that is not directly included in your project. It then tries to find a source file that includes the .h file as it will give more precise IntelliSense results.

Normally it should try the previously open source file first and should be fairly fast. However, if you are using an older PC, it could slow things down. You can also disable the entire Clang IntelliSense via Tools->Options->VisualGDB->General->Tweaking->Enable Clang IntelliSense by default.

[support]

Hi,

Can you reproduce this on a basic “Hello, World” project as well? Perhaps your oscillator frequency is different from the one ESP8266 expects and you need to change it in the code?

Please also try changing the FLASH type from qio to dio and other types in VisualGDB Project Properties.

[support]

Hi,

Thanks for your feedback. The VS colors do sometimes get confused and restarting VS usually helps. Could you please explain the “changing a file then waiting while clang rescanned all my files” thing? We have designed the Clang engine to build the database in the background and only once (or when significant amount of files have been changed). If this is broken, we would certainly like to know so that we could fix it.

Please also let us know which Clang options you found confusing so that we could document them better.

[Author]

Posts