[support]

Hi,

Thanks for the suggestion, it indeed looks like a useful feature. We will look further into it and will post an update here next week.

[support]

If you are changing the command line in VisualGDB project properties, rather than running VisualGDB manually, you do not need to specify the gdb port. Simply use -c “init; halt; esp appimage_offset 0x20000” instead of init; halt” -c “esp appimage_offset 0x20000” that you tried before. Please also make sure there is a space before -c.

[support]

Hi,

Sorry for the confusion. The correct command line should be:

C:\Users\bope02\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp32.core\bin\openocd.exe -c “gdb_port 54502” -c “telnet_port 54500” -f interface/ftdi/esp32_devkitj_v1.cfg -c “adapter_khz 3000” -f target/esp32.cfg -c “init; halt;esp appimage_offset 0x20000” -c “echo VisualGDB_OpenOCD_Ready”

You can also do this:

-c init -c halt -c "esp appimage_offset 0x20000"

 

[support]

Thanks, we have reproduced the problem and found the root cause.

When CMake introduced a new optimized format for reporting CFLAGS for source files, we added a translation layer that allowed VisualGDB to handle both old and new formats. Turns out, the translation layer was not properly handling the sources that didn’t have any CFLAGS attached to them. This would only affect solutions with both VisualGDB and non-VisualGDB projects, and only when CMake would use the new code model format.

Either way, we have fixed the issue in the following build: VisualGDB-5.6.109.4813.msi

[support]

Thanks for clarifying this. CMake projects indeed handle the header files differently (depending on how CMake reports them and a few other settings), so some combination of settings might prevent IntelliSense from prioritizing them over the VS project.

We should be able to fix it promptly if you could create a simple repro case – a solution containing:

1. A basic Win32 C++ project referencing the header
2. A basic CMake-based project referencing the header the same way your current setup does it

If you can confirm that the problem persists in the repro solution, please try packing it into an archive and attaching it here (or using a file hosting service). BTW, the easiest way to check whether a file is using Clang IntelliSense is via the “Go” button on top of the file (see this page).

[support]

Hi,

Thanks for renewing your support.

If the solution contains multiple projects and you open a header (or source file), VisualGDB checks which of the projects explicitly reference that file. If the file is explicitly referenced by a non-VisualGDB project and not referenced by a VisualGDB-based project, it will let Visual Studio handle IntelliSense.

The workaround is extremely straight-forward: simply include the file in question in your VisualGDB-based project (Add->Existing file in the context menu). Since header files are not built directly, this won’t affect the build process, but will make sure VisualGDB uses the Clang IntelliSense engine when editing this file.

[support]

Hi,

It should normally not be necessary – in our tests OpenOCD managed to find everything automatically. Either way, please follow the steps below to resolve it:

1. Try starting a debug session. Take a note of the OpenOCD command line at the beginning of the Debug->Windows->VisualGDB Output window.
2. Try adding -c “esp appimage_offset 0x20000” at the end of the Command Line setting under VisualGDB Project Properties -> Debug Settings -> Advanced Settings (bottom of the page). You should not normally need the “init; halt” part.
3. Try starting another debug session. Take a note of the updated command line in the VisualGDB Output window.
4. If this does not resolve the problem, please try adding the “init; halt” part as well.

If the problem is resolved, please share the full command line so that we could look further into it and make sure VisualGDB handles it automatically.

 

[support]

Hi,

We are sorry for the inconvenience and will try to explain the motivation behind our support limitations.

We have previously tried doing exactly as you suggested – spend as much time as possible to unravel such issues for our customers. It didn’t work at all. Whenever we helped them untangle everything, they would very quickly come back with another problem in a different project, then another one, with more to follow. The complexity and amount of these problems would grow exponentially to the point where we would not be able to unwind them anymore. They would then blame VisualGDB for being useless and leave extremely frustrated.

We spent a lot of time trying to figure out why some users are mostly happy with VisualGDB, while others continuously run into problems where virtually nothing works. We found one particular difference: the bug reports that we are able to reproduce are usually separated from the greater context (e.g. other libraries, projects created earlier, etc). They start from scratch and show that using some specific settings together results in something unexpected. We usually fix such issues very fast, or suggest reasonable workarounds.

The bug reports where we cannot do anything follow a different pattern: a complex setup involving non-trivial projects, typically no notes, no source control, and the users are not sure what exactly they did to trigger the problem. This could be very easily avoided by using source control and keeping detailed notes of any changes you do to the environment (e.g. install new libraries, synchronize sysroot, etc). If you do not have that, it is really easier to re-create everything from scratch. This is not specific to VisualGDB, these are generic best practices that would save you lots of time with any IDE or tool. If you still don’t believe us, you can do an experiment – ask a friend to change a few random settings in a complex project until it breaks, and measure how much time it would take you to find what was changed without having the change logs. It will take orders of magnitude more time to find the problem than it took to create it. While having notes and source control, where you can just take a few steps back, would make it almost instantaneous. Again, it’s not specific to VisualGDB – it comes from the general complexity of the setup involving multiple libraries, toolchains and frameworks.

As for VisualGDB alternatives, if you know any similarly priced product that would investigate customers’ projects without charging an hourly rate, we would be more than happy to analyze how they manage to achieve it, and try to offer something similar. We are not aware of anyone being able to do that though – asking for the repro steps is a standard practice when it comes to complex software that involves many components coming from different sources.

Regarding the tutorials, we usually update them when there are non-trivial changes to the GUI (prioritizing by the number of tutorial views). We do not update them for cosmetic changes of the GUI, and we do not update the tutorials that have relatively little views. If you can point out a specific tutorial that is confusing given the latest VisualGDB, and provide more details on what you find confusing, we will try to address it.

With turning off customers, we are merely trying to set realistic expectations. If you divide the VisualGDB maintenance price by 12 months, you get way less than an engineer’s hourly rate. This is possible because many common VisualGDB features work the same way for multiple users, so the effort took to develop them scales up. Project-specific support does not scale – it’s unique to each user. So the support that can be realistically offered at this price comes down to pointing out the relevant documentation (and often updating it based on popular requests), and troubleshooting issues that can be reproduced and fixed in reasonable time. We do absolutely offer the in-depth troubleshooting screen sharing sessions for quickly solving the toughest problems, however we do charge our consulting rate for it, as it’s not viable to offer it at less than $10/month.

[support]

Hi,

This likely happens because you have both VisualGDB-based and non-VisualGDB-based projects in your solution. We can help you troubleshoot this, however we would kindly ask you to renew your support first via this page: https://sysprogs.com/splm/mykey.

[support]

Hi,

The log comes from the OpenOCD tool, that is maintained by Espressif, so we do not have much insights into it. You can try downloading OpenOCD from Espressif directly, running it manually per their instructions, and checking if it works. If it fails with the same error, please consider posting on the Espressif’s forum, perhaps they have a better idea of what’s going on.

If OpenOCD works when running it manually, but doesn’t work with VisualGDB, please let us know and we will walk you through getting it to work with VisualGDB as well.

[support]

Hi,

This type of error happens when users change multiple settings at the same time, forget what was changed, and end up selecting the settings that don’t make sense in their context. We suggest re-creating the project from scratch because it dramatically reduces the complexity of the whole setup – instead of checking every possible setting that could be causing the problem, you start from scratch, double-check that a handful of options selected in the wizard makes sense, and end up with a working project.

You can then compare that project against the broken one using a diffing tool (e.g. KDiff3) and quickly find out the mismatching setting.

The best way to avoid this type of problems is to change one setting at a time, verify that everything still works, and make frequent commits to your git repository, so that you can easily roll back to the last configuration that worked. We even have a separate page urging our users to follow this practice, but we still get a fair share of inquiries where the project is broken, the user is not sure what exactly they changed, and they are hoping that we can rescue a non-trivial project that we have never seen before.

Regarding this specific error, there isn’t much we can add to the error message: you somehow ended up with a toolchain that doesn’t match your SD card image. We don’t know what exactly you changed to get to this point, so we cannot point you to one specific setting that will undo it. If the newly created project works while this one doesn’t, please try comparing the .vgdbsettings/.vgdbcmake files between them – it should help you find the critical difference. If you can point to a specific XML element in the settings that is different, we can point you to the GUI setting that controls it, but it should be straight-forward in most cases.

[support]

Hi,

It could be a bug in a particular OpenOCD version then. You can always revert to the previous version as shown here: https://visualgdb.com/support/oldpackages/

Restoring the previous OpenOCD and doing a full FLASH erase via esptool.py should completely reverse any changes done by the newer OpenOCD.

[support]

Hi,

This looks like a known issue of the ESP32 OpenOCD. Please see this thread for details.

In order to flash the application via USB as the thread suggests, you can use the “Program FLASH Memory” command in the context menu in Solution Explorer (you would need the make sure the virtual COM port used for programming has the correct drivers installed).

[support]

Hi,

Thanks, we have rechecked the debugging log. Indeed, the optimization done by the ARM compiler prevents VisualKernel from properly intercepting printk() calls. It does work fine on x86 and x64 targets, however not on ARM. We will try to address it in the further releases, but won’t be able to promise anything at this point.

Regarding the kernel building, there was indeed a glitch that invoked an incorrect command line. We have fixed it in this build: VisualKernel-4.0.3.2334.msi

[support]

Hi,

Manually generating build scripts with VisualGDB requires a valid license. Please make sure VisualGDB is activated by running VisualGDB.exe /about and entering your activation key there.

[Author]

Posts