[support]

Hi,

Thanks for the video. This is totally expected. In order to do reliable stepping, gdb needs 2 mechanisms:

1. To be able to step one instruction at a time
2. Once it steps into a function, it needs to set a breakpoint on either the first code line of that function (for stepping into) or on the first line after the calling line (for stepping over).

On ESP8266 both mechanisms don’t work reliably:

1. Stepping instruction-by-instruction often triggers interrupts and gdb does not know how to step out of them
2. ESP8266 supports only 1 hardware breakpoint at a time, so if you already have one breakpoint in your code, gdb cannot set the temporary breakpoint as described above.

Additionally to that, gdb does not know how to reliably unwind the call stack on ESP8266, so if the target starts running some pre-built library code from Espressif, you see the ‘frame not in module’ message and don’t get a meaningful call stack.

These issues don’t happen with ARM devices because the ARM platform is very old and these problems were solved long ago. So for ARM devices, VisualGDB relies on the free tools like gdb to provide basic functionality (like stepping) and builds advanced features (like real-time watch) on top of them. For ESP8266/ESP32 there are no reliable low-level debugging tools and making them on our side would drive the VisualGDB price sky high (you would probably not want to pay $5K to debug a $2 chip), so unfortunately VisualGDB has to depend on the unreliable open-source tools that may be eventually fixed by the chip vendor. Hence <3$ for an IoT device is indeed compelling, however unfortunately you end up paying with spending several times more time to accomplish the same basic results.

We may eventually consider creating a list of the low-level tool issues and launching a crowdfunding campaign to fix them in the free tools, but it is hard to say how successful this would turn out.

We hope this explains it and sorry for the inconvenience caused by this.

[support]

Hi,

Thanks for confirming this. ESP8266 and ESP32 devices are relatively new and the debugging experience is often unreliable. Knowing the limitations, it is usually possible to get meaningful debug sessions, but the usability is unfortunately never near the ARM-based devices. VisualGDB tries to address some of the issues like disabling watchdogs and programming SPI FLASH, but there are unfortunately still many missing pieces.

[support]

Hi,

You can always explicitly specify which linker script file to use via VisualGDB Project Properties. As long as it is specified, including .lds files in the project should not affect anything.

[support]

Hi,

The options shown in the tutorial were added to the new profiler package released just before 5.2R8. Please install it via Tools->VisualGDB Package Manager->Updates.

The new package also adds an option to exclude the sampling profiler code, so you won’t need to modify the code anymore.

[support]

Hi,

Please try adding them to Solution Explorer.

[support]

No problem, the -s switch should be supported on all systems, so we have switched VisualGDB to using it. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1376.msi

[support]

Hi,

Looks like your project includes files meant for the IAR compiler (IAR\ARM_CM3\portmacro.h). Please double-check the list of imported files and the preprocessor macros and ensure that only files meant for GCC are included.

If you are using Clang IntelliSense, you can quickly check why a certain file was included by opening it in Visual Studio and checking the bar on top of the source file. It will show the source file that includes the header and the entire inclusion stack.

[support]

Hi,

Thanks for reporting this, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1375.msi

[support]

Hi,

VisualGDB does not cache the headers from the WSL, instead it configures the IntelliSense to directly look inside the WSL directories.

If you are using CMake on WSL, you may be affected by a bug that prevents VisualGDB from querying CMakeLists.txt properly. If this is the case, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1375.msi

[support]

Hi,

We have rechecked the sample project and it had 2 references to the system_stm32f0xx.c file: one from the BSP and another one from the STM32CubeMX project.

Please remove the reference to the one from the BSP via VisualGDB Project Properties -> Embedded Frameworks -> Default System file, then rebuild the project (Build->Rebuild All). This should get the build to work.

[support]

No problem. Let us know if you need advice on interpreting the section offsets/sizes.

[support]

Hi,

We had it available as an option and less than 1% of our users actually enabled it (still causing troubles due to spamfilters). Sorry.

Regarding the on-page notifications, you can get a brief overview of the recent replies by clicking on your username near the post and then selecting “topics” (e.g. https://sysprogs.com/w/forums/users/bmcdonnell_psi/topics/). Each topic will show the last post time.

We understand that this may not be the most usable way to display topics and updates, but due to priority constraints we have to rely on the existing forum engine without doing serious modifications to it.

[support]

Hi,

Sorry for the delayed reply. We have reviewed the process of making a custom cycle counter driver for real-time watch and profiler and published a detailed tutorial here: https://visualgdb.com/tutorials/profiler/realtime/cyclecnt/

Let us know if you encounter any troubles with it.

We also recommend updating your profiler package via VisualGDB Package Manager and using the latest pre-release build of VisualGDB: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1374.msi

[support]

Hi,

Thanks, we have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1374.msi

[support]

Hi,

Unfortunately the Visual Studio extensibility API cannot handle variables in .cpp file paths properly, so VisualGDB has to use relative paths with the user name.

It will automatically update those paths if you open the project on a different machine where the paths are different. Another option would be to relocate the BSP to a location under the source control (see this tutorial). Then VisualGDB will use relative path to that location.

[Author]

Posts