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

[support]

Hi,

Sure, if you already have a scatter file, you can specify its location via either VisualGDB Project Properties -> MSBuild Settings -> Linker Script or MSBuild Project Properties -> Linker -> Memory Layout -> Scatter file, and VisualGDB will pass it to the Keil linker. The only limitation is that VisualGDB won’t be able to automatically edit it to add new memories (i.e. the Additional Memories page won’t work).

[support]

Hi,

According to this log, VisualGDB tries to run the setup script from ESP-IDF (C:\Users\Mattia Berton\AppData\Local\VisualGDB\Python3\python.exe c:\sysgcc\esp32\esp-idf\v5.0\tools\idf_tools.py install-python-env) and it fails with an error.

Please try running the same script manually. If it fails with the same error, the issue is not on the VisualGDB side and is caused by something else in your system. You can try reaching out to Espressif to see if it’s a common issue with a known workaround. Once you get the script to work outside VisualGDB, it will work with VisualGDB as well.

[support]

Hi,

No problem, please see the answers to your questions below:

1. VisualKernel intercepts the printk() output by setting breakpoints in the functions responsible for processing of the printk() messages. On some platforms, the optimization level/debug symbol settings would interfere with it. Feel free to attach a gdb log so that we could recheck it.
2. The second issue looks like either your JTAG connection is unreliable, or something prevents the chip from responding to the JTAG commands. If you believe the issue is on the VisualKernel side, please try running OpenOCD and gdb manually. If it works outside VisualKernel, we can help you configure VisualKernel to support this setup as well.

[support]

Hi,

No problem. We have updated the OpenOCD package on our side to include the new definition file.

[support]

Hi,

Thanks for the detailed repro steps. It looks like you are using the ARMClang toolchain that uses Keil-specific scatter files instead of GNU linker scripts.

Unlike the GCC linker scripts that typically come from our BSPs and follow the same structure, the scatter files come from the Keil packs and can have an arbitrary structure, hence VisualGDB cannot edit them fully automatically.

We have updated VisualGDB on our side to show a warning on the External Memories page when using a non-GCC toolchain.

As a workaround, please consider creating a scatter file manually as shown on this page. You can configure the scatter file used by the project via VisualGDB Project Properties -> MSBuild Settings -> Linker Script or MSBuild Project Properties -> Linker -> Memory Layout -> Scatter file.

[support]

Please make sure you use an unmodified version of the VisualGDB installer with a valid license.

[support]

Hi,

Most likely, the device uses a different USB VID/PID, that is not recognized by VisualGDB. From a quick look at the original .cfg file, it looks like ST recently added the 0483/3754 ID, so that’s likely corresponds to the new device.

Please try replacing the edp.xml and the files in the QuickSetup directory under %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd with the ones from the attached archive, then restart Visual Studio.

Please let us know if it solves the problem, and we will release an updated OpenOCD package with the correct definition files.

 

Attachments:

You must be logged in to view attached files.

[Author]

Posts