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

[support]

Hi,

Yes, sorry, it’s currently a limitation of the Clang IntelliSense engine. We may support it in further versions, but currently it won’t work unless you switch back to the native VS IntelliSense.

[support]

Hi,

The easiest way to achieve that would be to disable the normal source uploading and then do it via a custom pre-build action after running your script. If this does not work, please let us know.

[support]

Hi,

The USB communication device example only supports the CDC (communication device) class. The mass storage class requires completely different source files.

Please update to the final release of VisualGDB 5.2, then update your STM32 BSP to the latest version. Then you will be able to select “Show STM32CubeMX samples” on the Sample Selection page and pick the “FatFS_USBDisk” example that shows the use of the mass storage class.

 

Regarding the ‘import recursively’ command, it’s only supported in the Custom edition and higher. If you are using the Embedded or Linux edition, you can add the files manually (one directory at a time). The header discovery will still work as shown in the tutorial.

[support]

Hi,

If the .so library is built by a VisualGDB project, you can simply reference the project via Add->Reference. If not, you would need to manually add the following command to GDB startup commands:

set solib-search-path <directory on Windows where the .so file is located>

[Author]

Posts