[support]

Hi,

Please try the latest v5.2R2 and retest your toolchain. It should generate the following definition for __cplusplus

#undef __cplusplus
#define cplusplus <version>

This should fully override the default value on all VS versions.

[support]

Hi,

The “import folder recursively” feature is available starting from the Custom edition. You can always upgrade your VisualGDB here: https://sysprogs.com/splm/mykey

Regarding MBED_CONF_NORDIC_UART_HWFC, it’s a known issue of the current mbed 5.2 beta BSP. It can be safely ignored and will be resolved in the final release.

[support]

Hi,

Please try switching the debug method to full-custom mode. Then specify the following:

Arguments	–interpreter mi $(TargetPath)
Working directory	$(ProjectDir)
Target selection command	source connect.gdb
Start command	Assume the target is already stopped

Then create a file called connect.gdb in your project directory and paste the attaching commands there:

target extended-remote COM3
attach 1

Then finally go to the Additional GDB Commands page and add the following post-target command:

load

[support]

Hi,

You may want to create a separate Linux and Windows configurations for that. Please check this tutorial: http://visualgdb.com/tutorials/porting/linux/

[support]

Hi,

VisualGDB supports STL containers out-of-the-box and provides 2 mechanisms to support custom structures:

• Type visualizers
• Natvis

If you believe some of those are not working properly, feel free to start another topic with details and we will investigate.

[support]

Hi,

You can do that via Visual Studio Project Properties -> C/C++->Advanced->Language standard for C files.

[support]

OK, we have added it to this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.13.1294.msi

[support]

Hi,

Please try the final VisualGDB 5.2 release. It contains the fix mentioned here.

[support]

Hi,

This could be caused by a problem that was solved in VisualGDB 5.2. Please try updating to it and resynchronize your toolchain sysroot.

[support]

Hi,

No problem. Library names can sometimes be confusing. Generally searching for *.so and *.a files containing the missing function name usually finds the correct one quickly.

[support]

Hi,

Most likely your VisualGDB is using the old package catalog that refers to an older version of the toolchain that has been removed due to problems with mbed.

Please install the toolchain via Tools->Embedded Tools Manager->Online. This will reload the up-to-date package catalog and install the latest version that includes all the fixes.

[support]

Hi,

Our toolchain is based on the regular GCC sources + some patches (see the gcc.patch file inside the toolchain directory).

Although we don’t ship this file with our toolchain, we have uploaded it to the following path for your convenience: http://sysprogs.com/files/tmp/newlib.h

[support]

Hi,

Please try updating to the latest gcc 6.3.0-r3 toolchain. We have fixed a problem that might have been causing this.

[support]

Hi,

It does, but if the same port is open by gdb that expects special gdbserver packets, it’s somewhat tricky to get that output out.

Please try running the ‘set debug remote 1’ command to force gdb to dump the communication with the gdbserver. This might force it to display the exception information “as is” instead of simply discarding it.

[support]

Hi,

Sorry, ESP8266 devices are simply not reliable and highly undocumented and often stop working sporadically. If reliability is a priority, we recommend trying the CC3200 chip from TI. It’s more expensive, but is much more reliable.

Regarding the questions below:

1. OpenOCD does require the libusb driver for Segger J-Link and will not work with the default Segger driver.
2. Our OpenOCD implementation only supports software breakpoints for functions in RAM. We recommend moving the actively debugged functions to RAM for the duration of debugging.
3. Unfortunately there is no official documentation on ESP8266 watchdogs. Our OpenOCD implementation uses the watchdog feeding mechanism used by the Espressif GDB stub. It is sufficient to step through examples like HTTP server, but it could be that some code in the internal ESP8266 libraries activates some mode that conflicts with this mechanism.

Sorry, as mentioned before, the lack of official documentation and general low reliability makes ESP8266 debugging not as smooth as for ARM devices. We try to provide workarounds for most known problems, but in many cases things don’t work as expected.

[Author]

Posts