[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.

[support]

Hi,

The gdb stub relies on running code on the same processor as your program, so many crashes would render the stub itself unresponsive. Debugging over JTAG could be a better alternative.

The stub also does not support breakpoints in FLASH. Please try moving your functions to RAM in order to set breakpoints in them.

[support]

Hi,

The “no source file” problem usually happens when the debugged executable is missing the debug symbols or the source file belongs to a .so library that is not loaded yet.

Please try checking the list of source files known to gdb by running the “info sources” command. Perhaps some symbolic links in some directories result in a different path for that file?

[support]

Hi,

This looks like a bug. Could you check the GDB Session window to see if VisualGDB is issuing the -break-after command properly to communicate the hit count to gdb?

[support]

Hi,

Are you using semihosting in your programs? The way semihosting works would cause the program to stop if a debugger is not attached. Please try making the calls to printf() and other semihosting-related functions conditional so that they don’t trigger in the release configuration.

[support]

Hi,

Sorry, generating warnings in this case would require modifying the compiler, and we would rather not risk breaking things with that. The only workaround we could suggest is to quickly use the Memory Explorer window to double-check the sections for specific functions of interest.

[support]

Hi,

Sure, we will add this to the next maintenance release of VisualGDB 5.2.

[support]

Hi,

This could be caused by VisualGDB setting some implicit breakpoints and using the one and only hardware breakpoint of ESP8266. Could you check this by entering the ‘info breakpoints’ command in the GDB session window and seeing if there are any breakpoints not explicitly set by you? If yes, does deleting them via the ‘delete’ command help?

[support]

Hi,

Yes, we’ve encountered some troubles with mbed 5.2.1 requiring bootloader on some targets and a few minor build issues. We will be publishing a beta version of the mbed 5.2.1 BSP in a few days. It won’t work out-of-the-box on 100% targets, but will be usable otherwise.

[support]

Hi,

We don’t have a tutorial specific to odroid, but most of the steps for Raspberry Pi and other boards should be the same.

[support]

Hi,

The library should be added automatically as long as you reference the corresponding project from your main project. Perhaps you missed that step or something went wrong and the reference was not handled correctly?

[Author]

Posts