[support]

Hi,

Looks like the programming succeeds, but your board might be using a different clock frequency or different UART pin numbers. Please try changing the gdb stub baud rate to 115200 (or look up the correct value in the board documentation). You may also need to edit the gdb stub to use a different UART port.

If you are not sure about the exact steps, please try using one of the boards directly supported by VisualGDB instead (e.g. Olimex mod-wifi-esp8266-dev).

[support]

Hi,

Strange. Just to double-check: does this happen before installing VisualGDB, or after?

[support]

Hi,

It looks like Microsoft is trying to add many new features in VS2017 and that indeed sometimes compromises stability. It’s hard to say whether anything could be done on VisualGDB side to fix this – we regularly test VisualGDB with the latest VS updates (that includes updating existing VS installation with VisualGDB), however have never encountered any problems on any of our test machines. Reinstalling VS/Windows could be indeed the fastest way around this, sorry.

[support]

Thanks, this looks like a corrupt installation. Reinstalling VisualGDB/Visual Studio should normally help.

Please also note that your technical support has expired. In order to keep on receiving support, please renew your license (or update your profile email so that it matches the new license email).

[support]

Hi,

Thanks the for the update. We will try to include support for new devices in our next refresh of the AVR toolchain.

[support]

Hi,

Normally the command should work (unless you enter it in the “additional gdb commands” and your debug preferences override it). Either way, the recommended way of handling this is using the “Interrupts” window of VisualGDB (click the lightning icon in the GDB Session window). VisualGDB will let you modify signal handling from there and will also remember the settings for the next debug session.

[support]

Hi,

Please update to the latest VisualGDB 5.3R7. The problem is fixed in that version.

[support]

Hi,

This is explained in step 22 of the tutorial. Please follow the instructions shown in step 23 (the debug settings page will look slightly different due to a recent update to our OpenOCD debug method).

[support]

Hi,

Normally you should be able to do it by following the esp8266 gdb stub tutorial. If it doesn’t work, please let us know if the programming stage succeeds (progress bar showing programmed addresses) or whether the device never enters the bootloader mode.

[support]

Hi,

This looks like an invalid path specified in one of the commands, rather than an incompatibility with mbed. We would advise double-checking every modification to Makefile you made just before this problem started occurring. If you are not sure, please try following the tutorial from the beginning and double-checking that the projects build successfully after each step. Once you locate the step that breaks the build, please double-check the edits made in this step.

If you don’t understand the meaning or role of some edits/custom commands, let us know and we will update the tutorial explaining them in more detail.

[support]

Hi,

Thanks for your feedback. We are currently researching possible approaches for Arduino integration and the ability to import existing community libraries sounds like a useful feature.

[support]

Hi,

The multiple nested breakpoints occur when one line of source code corresponds to multiple addresses (and hence needs multiple physical breakpoints). The usually happens with inlined functions or templates (e.g. list<int>::sort() vs list<string>::sort()).

It is hard to say why would this make VS hang. One guess would be that gdb needs to update too many physical breakpoints each time you stop the session and this takes time. You can try running the “set breakpoint always-inserted on” command to prevent gdb from updating breakpoints each time the session stops.

If this doesn’t help, we would recommend narrowing it down to a specific breakpoint (e.g. measuring break-in delay with and without it) and checking if this can also be reproduced without VisualGDB. If not, some gdb options or initialization commands could be affecting it. If yes, it’s likely a limitation of gdb and not much could be done to work around it other than generally speeding up connection to your target.

[support]

Hi,

This looks like VisualGDB mistakenly assumes that those files belong to a VisualGDB-managed project. Please try the following:

1. Close your solution.
2. Clear the Clang diagnostic log.
3. Reopen the solution and open one source file. Ensure the problem persists.
4. Post the entire Clang log here. It should explain what projects are considered open by the IntelliSense and why it attaches to your files.

Also as a quick workaround while diagnosing this you can change the default engine on the Clang IntelliSense Diagnostic Console to “VS IntelliSense” while not working with VisualGDB projects. This should prevent it from attaching to the files unless the project referencing them explicitly enables Clang IntelliSense via settings.

[support]

Hi,

The window displays various service information that is required for us to check whether VisualGDB is initialized correctly. We also could not find any orders associated with your email address. Please let us know the address associated with your license.

[support]

Hi,

Thanks, we have tried reproducing this with your template file, but unfortunately could not get anything similar. Most likely the problem is caused by some combination of installed/referenced toolchain versions. If this is too annoying, we can add extra diagnostic logging to the logic responsible for the toolchain selection, so it will explain what is causing this with your setup. Let us know if you would like to try it out.

[Author]

Posts