[support]

Hi,

Thanks for confirming this. For MSBuild projects the setting should be under VS Project Properties (not VisualGDB Project Properties) -> Embedded Project -> Generate Binary File.

[support]

Hi,

Yes, please let us know your project type (MSBuild or GNU Make) and we can point to the specific location of this setting.

[support]

Hi,

Yes, as long as you have the “Generate Binary file” enabled in VisualGDB Project Properties (or VS Project Properties for MSBuild-based projects), VisualGDB should generate .bin files that can be simply programmed to the FLASH memory (offset 0 from the beginning of FLASH).

[support]

Hi,

OK, thanks for clarifying this. This indeed looks like the parsing itself is taking a lot of time. If you are opening the project for the first time, this is to be expected – VisualGDB will build various caches and the subsequent operations should take much less time. If anything else is slow beyond the initial delay, please let us know and we can help you pinpoint it.

[support]

Hi,

Thanks for pointing this out. We will consider making it more intuitive in one of the next versions.

[support]

Hi,

Thanks, this makes sense. Most likely the delay comes from accessing the source code over network. Any remotely located include files that are not a part of the precompiled header would add considerable delays to the parsing due to network latencies. Please try storing the files on the Windows machine and see if this improves performance.

Another way to diagnose this would be commenting out different parts of the main .cpp file and checking how this affects reparse time (e.g. first comment out everything except the #include<> directives at the top, then comment out the lower half of the source file, etc). Please note that each time you modify the preamble (#include<> statements at the beginning of the file), VisualGDB will rebuilt it, showing a greater increase in the reparse time. The next reparse will be much faster.

[support]

Hi,

VisualGDB tries to inherit the regular Visual C++ formatting settings under Tools->Options->Text Editor->C/C++, so please double-check that the indentation settings there match your expectations. If VisualGDB still indents the code the wrong way, please attach a screenshot of the relevant VC++ setting and a screenshot of a formatted code fragment and we will try investigating this further.

[support]

Hi,

You could try cloning this repo and building it (this might be non-trivial, sorry). Please check all the branches, as the master branch might not be up-to-date.

If you get it to build, we can provide instructions on modifying the scripts to specify the ST-Link v2 serial numbers so that OpenOCD can understand them.

Another option would be to try one of the Olimex debug probes. They are based on the FT2232 chip that basically exposes the low-level JTAG and SWD interfaces directly to OpenOCD, so all the functionality that works with ST-Link will also work with their devices.

[support]

Hi,

Sorry, VisualGDB doesn’t provide any hooks that are executed when a library is loaded, however you can work around this as follows:

• If you are debugging directly on the target, simply strip the symbol information from the libraries you don’t want to debug using the strip command (make backups in case you need the debug information later).
• If you are debugging with a gdbserver, setup a directory on the gdb machine with the symbols you want to load (copy the updated symbol files there via custom actions) and ensure no other symbol files get there. Then replace the solib search path by with a path consisting of only that directory. Hence gdb will locate the libraries you want to debug and will skip the rest.

You can also try indexing your symbols as described here, although in our tests we couldn’t get any significant performance improvement, so we decided not to do it automatically.

[support]

Hi,

Strange, perhaps the reply did not get posted due to corrupt cookies or some proxy issues. Either way, good to know it works. If you encounter any further problems, don’t hesitate to let us know and we will help.

[support]

 

Hi,

Normally just pointing it to a header file with multiple #include-s should do the trick. You can double-check if it’s being included by defining a macro inside the file (e.g. #define TEST_PCH) and then checking for it in your code:

#ifdef TEST_PCH
#error test
#endif

The IntelliSense should then highlight the “test “error (it won’t affect compilation). If the macro gets propagated properly, but the IntelliSense is still slow, please let us know what exact operation is slow, attach a quote from the Clang IntelliSense Diagnostics console and a screenshot of the timing report (timer icon at the top right corner of the navigation bar) and we can help you optimize your IntelliSense experience.

[support]

Hi,

It looks like something is preventing the git command to clone the ESP-IDF repository. Please check the output of the git command shown in the progress window for clues. If you are not sure, please post it here and we can help you understand it.

[support]

Hi,

Thanks for explaining this – it makes sense. Good to know you have found the workaround. Let us know if you run into further problems and we will be happy to help.

[support]

 

Hi,

Yes, that might work, although due to differences between the VC++ and the gcc compiler, some features might still not be supported properly.

[support]

Hi,

Sorry, we only provide technical support to registered users of our paid products. In order to keep on receiving technical support, please let us know the email address associated with your license.

[Author]

Posts