[support]

Hi,

VisualGDB includes a separate IntelliSense engine optimized for GCC-specific code (like most embedded libraries), so its settings generally differ from the regular C++ settings. That said, VisualGDB detects and imports most common C/C++ language settings from the regular C/C++ pages, so you don’t need to set the same settings twice. If you believe this is not the case for some settings, please let us know and we will investigate.

You can easily combine VisualGDB projects and regular Win32 projects in one solution. If the same file is shared between VisualGDB and a non-VisualGDB project, VisualGDB will rely on Visual Studio to determine the project corresponding to the file. Depending on the VS version and settings, it may treat it as a part of the VisualGDB project or as a part of the regular VC++ project.

If this causes confusion, we would advise temporarily unloading irrelevant project during development so that Visual Studio could uniquely identify the projects for all source files.

[support]

Hi,

IntelliSense should not be related to the fix we added for debug visualizers. Please try double-checking if you can get the same behavior with a minimal “hello, world” project. If yes, please post the code here so that we could check it (we quickly tried it with “std::make_unique<std::string>()->” and it worked as expected).

[support]

Hi,

Thanks for confirming this. The only other advice would be to ask in the clang/llvm mailing lists. This might be a known issue and someone from the clang community might be able to suggest a better workaround.

[support]

Hi,

If you are using a Custom edition or higher, you can create a custom pre-debug action (or a custom shortcut) to transfer the necessary files. Both can be configured via VisualGDB Project Properties; pre-debug actions are always launched before debugging, while custom shortcuts can be launched manually via Project->VisualGDB Custom Shortcuts menu.

Another option would be to simply add “*.xml” to the list of transferred file masks on the first page of VisualGDB Project Properties.

[support]

Hi,

Thanks, looks like the UART baud rate might be set incorrectly. Normally the initial gdb stub message should look like this:

$T05#b9

Please try setting the UART speed explicitly by calling the following function before gdbstub_init():

    UART_SetBaudrate(UART0, 74880);

If this does not help, please check the schematics of your board to see the crystal oscillator frequency. The default UART baud rate would be 115200 * (frequency / 40 MHz). E.g. for 26 MHz it would be 74880 .

[support]

Hi,

The mainstream OpenOCD usually starts supporting STM32 devices a few months after they are released (we rebuild our package from the latest sources regularly).

If you don’t want to wait, please try replacing the OpenOCD binary in %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin with the version from the AC6. Normally no script modification should be necessary, however if it doesn’t help, please try using the script from the AC6 distro as well.

If this does not work, please let us know and we will be happy to help.

[support]

Hi,

This could be the case. We would advise trying lldb-mi instead of gdb (LLDB is the debugger from the clang/llvm suite) that might work with clang-generated code better. VisualGDB supports it, although it is generally less feature-complete and less stable than gdb.

[support]

Hi,

No problem. Let us know if you run into any issues again and we will be happy to help.

[support]

Hi,

Please ensure the GDB stub is enabled on the first page of VisualGDB Project Properties and you call the initialization function from your entry function.

If this is the case, please try using the “test connection” button on the Debug Settings page and try experimenting with different UART speeds.

[support]

Hi,

With VisualGDB 5.3, the toolchain directory is always computed dynamically, so the workaround with creating environment variables is no longer needed.

With the missing pages, it looks like you are referring to the custom features that are not available in the Embedded edition. We have a detailed page listing all Custom-only features here. Let us know if you have any questions about it.

[support]

Hi,

VisualGDB uses randomized ports for J-Link and OpenOCD in order to support multiple debugging sessions at once. Normally it should choose a port randomly and configure both gdb stub and gdb to use it. Perhaps your firewall is interfering with it? If this is the case, please try adding JLinkGDBServerCL.exe to the list of exceptions.

If not, please check the command line used by VisualGDB to run segger gdb server (shown in the corresponding window in VS) and the ‘target’ command in the gdb session window. If the port numbers there don’t match, please let us know. If they do, please try running the same commands manually and see if it works and if there could be any other components (e.g. antivirus) blocking the connection.

[support]

Hi,

OK, this looks like a different error and should be very easy to fix. Please click the ‘repair’ link at the bottom of the MSBuild Settings page shown on your screenshot and VisualGDB will repair everything automatically.

With code analysis, the Clang engine could be disabled globally or may have troubles attaching to the project. Please check the View->Clang IntelliSense Diagnostics Console for initialization-related messages (e.g. close the solution, clear the console log and re-open it). If you are not sure, simply post the log here and we will help you understand what is going on.

[support]

Hi,

This looks like a buggy gdb build or some incompatibility between gdb and the debug information format. Were you able to debug your programs on that machine successfully before? If yes, we would advise trying to revert to the gdb version that worked.

Another option would be to check if the gdb hang is related to the debugged binary (e.g. does it hang with no debugged binary or with a simple “hello, world” program?). If yes, changing the debug information format (e.g. -gdwarf-2) might solve this. If the program consists of many large shared libraries, stripping the ones you don’t want to debug (using the ‘strip’ command) will reduce the amount of symbols loaded in gdb and could also improve performance.

Yet another option would be to try running gdb on the Windows side instead (note to other readers: this requires the Custom edition). With VisualGDB 5.3 it’s as easy as selecting “allow changing build/debug command host” on the first page of VisualGDB Project Properties, adding an action to download the built binary on Windows and then changing “gdb executable” on the Debug Settings page to your Windows gdb.exe (it needs to match the Linux target type). VisualGDB will then figure out how to use gdbserver and update the startup commands automatically.

[support]

Hi,

You can activate VisualGDB on the build server by running “VisualGDB.exe /about”. This will show the “About VisualGDB” window and let you enter the key.

If this does not work, please update to VisualGDB 5.3.

[support]

Hi,

Please find the answers to your questions below:

1. We indeed don’t support DA14580 yet. As a workaround please consider selecting “Specify flags manually” in the wizard and manually adding include directories/preprocessor macros specific for the device as shown in our legacy device tutorial. It also looks like the DA14580 popularity is raising over time, so we may add direct support for it later once we see enough interest for it. We also offer a service of creating BSPs for non-mainstream devices. Feel free to contact our sales if you need a quote.
2. VisualGDB provides an equivalent of the “-preinclude” command option via the “Forced Includes” option as shown below:

If you have any further questions, feel free to let us know and we will help you.

Attachments:

You must be logged in to view attached files.

[Author]

Posts