[support]

Hi,

First of all, thank you for the detailed feedback. The possibility to use a custom toolchain was designed as a fallback scenario, so it indeed may be quite cumbersome. Based on your inputs we should be able to improve it in the next release. As a temporary workaround, you can manually configure it using the instructions below.
1. VisualGDB is very conservative about changing toolchains because accidentally using a wrong toolchain (e.g. the one with an older version of GCC or mixing the toolchains that have hardfp/softfp enabled by default) can cause VERY hard-to-diagnose problems. GDB simply crashing at random times could be the least of the problems. Hence the normal GUI does not allow changing it. Now if you’re familiar with all the pitfalls and are willing to experiment with the toolchains at your own risk, you can easily configure VisualGDB to recognize them.

VisualGDB identifies toolchains by a toolchain ID (unique for the specific toolchain build) and the GNU target ID (e.g. arm-eabi). BSPs and debug methods are bound to a specific GNU target ID. Once a project is created, it is bound to a specific toolchain ID. Once you import a custom toolchain, VisualGDB will generate a unique ID for it and save it under HKCUSoftwareSysprogsVisualGDBThirdPartyToolchains. The toolchain summary will be saved to the toolchain.xml file inside the toolchain folder. The project will refer to the toolchain by its ID (the .vgdbsettings file points to an embedded profile file that in turn contains the toolchain ID).

If you want to switch a project to a new toolchain, please do the following:
a. Replace the generated toolchain GUID in toolchain.xml with a more human-readable ID
b. Edit the embedded profile file (e.g. lpc.xml or mcu.xml in the project directory) to refer to a new ToolchainID.
c. Open VisualGDB Project Properties and change the CPU type to something else and back. VisualGDB will regenerate all settings files to use the new toolchain.

Please ensure to rebuild your project after you do that. Also ensure you don’t mix code built with different toolchains.

2. The segger J-Link will only appear for the arm-eabi toolchains. If your toolchain uses a different ID (e.g. arm-none-abi or arm-elf), please edit its toolchain.xml to have arm-eabi. You can specify the GNU target ID when you are importing the toolchain.

3. If you don’t need the BSP, you can simply create a custom project. The only thing that you’ll need to specify manually is the linker script. Let us know if this is too inconvenient.
4. We have added the NXP LPC support fairly recently and don’t provide the hardware register layout yet. As a workaround you can generate a description file yourself. The easiest way to do this is to create an STM32 project and look into the stm32.xml file. If will contain a reference to a MCUDefinitionFile (in %LOCALAPPDATA%VisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32). You can use that file as a template for generating one for your MCU. Once you generated it, simply add a reference to it in the embedded profile file. Let us know if you need a C# sample for generating the definition files.
5. Yes, VisualGDB uses toolchain IDs (that are stored in toolchain.xml and referred to from .xml). Please ensure that the ID is the same on all machines.

6. We could add support for combining error message information from different lines, but that would cause confusion with multi-thread builds when several compiler instances are producing output. Would making a basic wrapper (e.g. using PERL) around the IAR compiler that will simply concatenate those lines be a viable solution for you instead?

7. We made it a global XML setting in assumption that the regex alternative syntax allows extending the GCC rules so that they will work for both GCC and the other compiler. If that does not work for you, we can add a per-project option as well.
8. We use the generated rules for sources with extra path because we could not find a reasonable way to make generic templates for those (given that the .o files go to the debug/release directories and don’t stay with the source files). If you have an idea how to achieve it efficiently, feel free to share it with us. Note that we generate the rules based on the templates at the end of the Makefile however, so editing the templates and then changing the source list will propagate your changes to all rules.
9. Thanks for letting us know, we will fix this in the next release.
10. We currently only support file exclusion for Android projects. In the long term we are planning to replace GNU Make with MSBuild-based building (like in vs-android). In the short term we recommend using the filter-out statements as a workaround.
11. Yes, the new engine is based on clang and won’t have that issue. As a workaround you can replace #ifdef _MSC_VER with something like #ifdef WINDOWS_BUILD and define WINDOWS_BUILD inside #if defined(_MSC_VER) & !defined(__GNUC__). As VisualGDB defines __GNUC__ via gcc_.h, this will allow distinguishing between the real Windows build and VisualGDB.

This is in our planned fix list, however as the workaround is fairly simple, the priority for it is relatively low. Let us know if it is too annoying.

[support]

Hi,

Do you see the same behavior if you select the “LibUSB-WinUSB” driver via the Driver Tool?

[support]

Hi,

Our build is using the source code from the official 0.8.0 release with the only modification being the Windows 8.1 fix (the package includes a patch file with all our changes to the source).
Could you please confirm that the original OpenOCD works with your hardware but our one does not given the same command-line arguments and driver?

[support]

Hi,

The custom remote console does not affect Android emulator options. It simply allows running a custom program and showing its output inside Visual Studio. E.g. if your program produces output via a TCP port, you can specify telnet : as the custom console and you will be able to see the output.
VisualGDB does not start Android emulator automatically. Instead it can launch the AVD Manager to let you launch it manually. If you want to override the environment that goes to the emulator, you need to either override the Visual Studio environment, or run the AVD Manager with the modified environment manually.

[support]

Hi,

Sorry, we tried reproducing it on our hardware (ST-Link v1 and v2) and could not get the problem. It looks like OpenOCD may not fully support st-link v2.1 at this point. Does the Texane/STLink tool work for your hardware?

[support]

Hi,

We use a special build of OpenOCD that contains a workaround to the LibUSB problem on Windows 8.1 (the source code modifications are included in the libusb_workaround.patch file together with the package). You mentioned that running the x64 OpenOCD manually works. Does running our build manually from %LOCALAPPDATA%VisualGDBEmbeddedDebugPackagescom.sysprogs.arm.openocd work as well?

The KARL – should read back as 0x03, not 60 02 00 00 message comes from the texane/stlink tool and it looks like it gets printed unconditionally:

static void init_code_breakpoints(stlink_t *sl) {
memset(sl->q_buf, 0, 4);

stlink_write_debug32(sl, CM3_REG_FP_CTRL, 0x03 /*KEY | ENABLE4*/);

printf("KARL - should read back as 0x03, not 60 02 00 00n");

stlink_read_debug32(sl, CM3_REG_FP_CTRL);



for(int i = 0; i < CODE_BREAK_NUM; i++) {

code_breaks.type = 0;

stlink_write_debug32(sl, CM3_REG_FP_COMP0 + i * 4, 0);

}

}

Most likely, it is safe to ignore this message.

[support]

Hi,

VisualGDB supports IntelliSense by providing configuration and compatibility definitions to the Visual Studio IntelliSense engine. However, some GCC-specific constructs still confuse it and cause false positives. We are currently developing an independent clang-based IntelliSense engine that will solve that problem. As a temporary workaround, you can right-click on the errors window and disable IntelliSense errors completely.

[support]

Hi,

LIBUSB_ERROR_ACCESS looks like a permission problem. Does running Visual Studio as Administrator help?

[support]

Hi,

You can also check out our UART tutorial explaining how to fix a similar issue: http://visualgdb.com/tutorials/arm/stm32/uart/

[support]

Hi,

Is uploading the same file with SmarTTY also slow? It is using the same SSH engine.

[support]

Hi,

Can you try starting the Driver tool (select ‘manual mode’ in OpenOCD settings) and trying to manually install the WinUSB-LibUSB driver for the ST-Link device?

[support]

Hi,

Most likely some of your symbols refer to an incorrect path. Can you try running arm-eabi-objdump -g and see if the file tables mentioned in the output contain some suspicious names? If not, can you try commenting out parts of your project to see which source file causes it?

[support]

Hi,

What is the final size of the binary you’re debugging? If it’s several tens of megabytes, it could explain why deployment is slow. You can speed it up by adding a custom action that will strip it and deploy a stripped version (don’t forget to disable auto-deployment and don’t strip the version used by GDB to read symbols). We could also add a deployment progress window if it turns out that the deployment is the bottleneck.

[support]

Hi,
Based on the log, the clean action fails because there is no project built yet (it should be normally ignored), but the build succeeds. Does the normal build command (not rebuild) work?

[support]

Hi,

The disassembly window in Visual Studio sometimes behaves strangely is some of the requested code ranges cannot be disassembled. Can you provide a screenshot of the Disassembly window, the address you’re trying to see and the corresponding GDB log showing what gdb reports when asked to disassemble those addresses?

[Author]

Posts