Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
You may want to create a separate Linux and Windows configurations for that. Please check this tutorial: http://visualgdb.com/tutorials/porting/linux/
November 10, 2016 at 21:16 in reply to: Unable to debug std::map when cmake is configured with flag -std=c++11 #9462support
KeymasterHi,
VisualGDB supports STL containers out-of-the-box and provides 2 mechanisms to support custom structures:
If you believe some of those are not working properly, feel free to start another topic with details and we will investigate.
support
KeymasterHi,
You can do that via Visual Studio Project Properties -> C/C++->Advanced->Language standard for C files.
support
KeymasterOK, we have added it to this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.13.1294.msi
support
KeymasterHi,
Please try the final VisualGDB 5.2 release. It contains the fix mentioned here.
support
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
Please try updating to the latest gcc 6.3.0-r3 toolchain. We have fixed a problem that might have been causing this.
November 7, 2016 at 20:53 in reply to: how to get exception information on esp8266 when crashes? #9432support
KeymasterHi,
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
KeymasterHi,
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:
- OpenOCD does require the libusb driver for Segger J-Link and will not work with the default Segger driver.
- 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.
- 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.
-
AuthorPosts