Forum Replies Created
-
Posts
-
Hi,
VisualGDB manages the STM8 debugging via OpenOCD – an open-source tool for interfacing gdb to various hardware debuggers. The STM8-specific logic is contributed by ST and is mostly located in the stm8.c file.
If you would like to change how OpenOCD handles the reset sequence, we would advise first locating the related logic in the OpenOCD sources. If there is an existing option for changing it, you can try adding it to the relevant OpenOCD script, or directly to the command line (use VisualGDB Project Properties -> Debug Settings -> Advanced to edit the OpenOCD command line directly). If there is no such option, you would need to patch OpenOCD and build a modified version yourself. We would advise following this tutorial to build our OpenOCD fork – it uses CMake and is much easier to build on Windows, compared to the mainline version.
If you end up patching OpenOCD to fix the issue, feel free to either submit a pull request to us, or send a patch to the OpenOCD mailing list, so that your patch gets included in subsequent releases.
Hi,
No problem, we will try to help you. The symbolic link error could be caused by your antivirus interfering with the Visual Studio process, or by invalid symlinks on the target.
The easiest way to track it down would be to enable the SysprogsSync logging via Tools->Options->VisualGDB->General->SSH->Log SysprogsSync Transfers. Once you try resynchronizing the directory again, VisualGDB will create a SysprogsSync.log file on the Windows side containing the detailed information about the transfer. Please try focusing on a single symlink that could not be set, and checking:
- Whether its value on the Linux side makes sense
- Whether the target file/directory got copied to the Windows side
- Whether the log file mentions anything particular about that symlink
If it doesn’t help, please share your findings along with the relevant parts of the log file, and we will try to help you get it working.
Thanks for confirming your license information.
VisualGDB displays the XMing GUI whenever any program running on the Linux side tries to connect to the X11 server in order to display the X11 GUI via SSH. Normally, it happens when explicitly running graphical Linux applications. Sometimes, the command-line tools try connecting to the X11 server as a part of initializing some libraries, that also triggers this GUI.
If you would like to find the root cause, you can try enumerating the processes on the Linux machine while the VisualGDB XMing prompt is still active, attaching to the suspect ones and checking the call stack. It should explain which process is trying to connect to X11.
A more universal solution would be to completely disable X11 forwarding for that host via Tools->VisualGDB->SSH Host Manager->Host-wide settings->X11 forwarding = Disabled.
We always run some basic tests on our toolchain packages before releasing them. We specifically test that the basic projects for most common devices can be built and debugged, and that the toolchain can be installed from scratch on a clean machine with Visual Studio, our latest 3.x Python package and the latest VisualGDB.
If you are experiencing different behavior, it means that you have done something differently. We do not have a crystal ball to see what exactly is different in your setup – all we can do is review the information you provide, compare it to our reference setup, and point out the differences that could be relevant. That’s why we ask for complete detailed screenshots of the entire steps from the very beginning – the root cause is often hidden in fine details (like spaces in paths or overriding something). The post #33578 does not provide any of that information. All it shows is that you are trying to do multiple things at once, so all we can suggest is to do one thing at a time.
Regarding the Espressif releases, they do it fairly often – publish minor updates with the same version, fixing some old issues and sometimes introducing new ones. As we don’t charge our users for toolchain updates, the amount of resources we can put into them is fairly limited – we update them a couple of times per year with major releases from Espressif. We would only do an earlier update if there was solid evidence that it would fix a major problem affecting multiple users. If you absolutely have to use the latest releases from Espressif with VisualGDB, please do take your time to understand how the toolchains, ESP-IDF and Python environments work together, so you can move them between the environment created by the Espressif installer and our toolchain. It requires some effort and troubleshooting, but it’s more realistic than asking us to rebuild, retest and republish the toolchain every time Espressif does a minor update. If you are just looking for a simple way to use ESP-IDF 5.0 (without the latest minor fixes), please do try to install our toolchain in a clean environment. It has passed our tests and we other users have confirmed that it works for them.
P.S. We have published a summary of cleanup steps for troubleshooting ESP-IDF 5.0 installation here.
Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.
Another common cause of errors is updating to a new toolchain/BSP/SDK. Many of these components are maintained by device vendors or communities, and require minor adjustments to the project when switching to newer versions. If you have recently updated any of such components, please consider reverting back to the old version as described here. There is no need to downgrade VisualGDB itself, as it is updated separately from such components.
You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.
Hi All,
@angel, @paulmartinsen – please make sure you use the latest VisualGDB 5.6R9. The older versions indeed do not support the new Python environment layout introduced in ESP-IDF 5.0 and will require manual setup.
@gojimmypi – please do read this reply. You keep doing multiple things at one and breaking them further and further. If you would like to get anything working, we urge you to read and follow the best engineering practices described here.This looks like another problem arising from doing multiple things at once. The files in ~/.espressif are created during the toolchain installation, so you likely had leftovers from the previous incomplete installs.
Based on your recent posts, you are running into a very typical beginner’s mistake documented here. You are trying to do multiple things at once using non-conventional ways, and then try troubleshooting them by manually overriding arbitrary parameters, which creates further problems exponentially. This never works, always results in lots of frustration and leads to a completely broken environment where you will have to reinstall your entire system to get things working. VisualGDB is not designed to work under these conditions and our support will not help you unless you start doing things one-by-one and carefully documenting each step, so we can review it and point out what went wrong.
Below are the specific examples:
- Instead of doing a clean install of the new toolchain, you ended up somehow merging the old and new toolchain (based on your report that the old IDF checkout went missing). Please do not do this. Please install each toolchain into a separate location and do not move files between them.
- Before you got ESP-IDF working on Windows, you tried using the same toolchain from WSL. Please do not do this. It could create Linux-specific files in some shared directories, preventing the toolchain from working on Windows.
- Instead of uninstalling VisualGDB normally, you somehow ended up deleting the license.rtf file (and possibly others) and then ran into the installer error. Please do not do this; deleting arbitrary VisualGDB files will lead to strange errors. Simply use the Add/Remove Programs GUI in Windows to uninstall VisualGDB.
- You have just submitted another inquiry asking for help integrating an overnight update from Espressif into your environment before you got everything working. Please do not do this; please make sure you got the existing environment working reliably, make backups of everything, and then attempt applying the update using the regular git workflow.
These are just the things you told us about; you are likely changing other parameters behind the scenes, that create more points of failure. Please do take your time and read this page, it provides a very detailed explanation why this approach always leads to problems and gives very solid recommendations for avoiding them.
Please note that our support is strictly limited to VisualGDB. If you encounter problems using the Espressif toolchain outside VisualGDB, please consider contacting Espressif for help.
Our ESP32 toolchain packages contain the toolchains and ESP-IDF checkouts published by Espressif, along with the XML files that allow VisualGDB to use them out-of-the-box. We do not modify the Espressif toolchains in any way and do not make any guarantees regarding their operation. They are developed by and maintained by Espressif, so please contact Espressif if you need help with them.
Hi,
You can install both toolchains side-by-side, as long as you use the “online” view in the VisualGDB Package Manager and manually specify a different directory (or just download and run the installer manually). The “update” view is intended for replacing the older toolchains, and will indeed overwrite it.
For convenience, you can always select to ignore a specific update, so VisualGDB won’t suggest it anymore.
Regarding the IDF versions, it sounds like you had experimented with manually installing extra ESP-IDF checkouts into your toolchain, and they got removed when VisualGDB uninstalled the old toolchain during the update process. This is to be expected, as mixing the parts from the old and new toolchain could result in very weird bugs.
In general, if you are playing around with multiple ESP32 toolchain and IDF checkouts, we urge you to keep good notes of the toolchain and IDF versions that work together and double-checking them when you clone the IDF releases manually. Accidentally combining unsupported versions often leads to strange errors.
If you would like to load it manually, just copying the .ko file and running modprobe/insmod should suffice (as long as it’s exactly the same kernel, you don’t need to rebuild it).
You can also copy the sources + Makefile and run make (note that the make command line would need to reference the kernel module script directory, e.g. see this page). Making the module load automatically depends on your Linux version and is usually described in your distro’s documentation. VisualKernel does not configure it automatically.
We have tested it with ARM-USB-OCD-H (see this page), but not with ARM-USB-TINY-H. Olimex probes are based on the same FTDI chip family, so it should work in theory, but we haven’t specifically checked it.
Hi,
No problem, we have released an updated toolchain based on the esp32-2021r5-patch tools with ESP-IDF 4.4.3. You can download it here: https://gnutoolchains.com/esp32/
Please make sure you use the latest VisualGDB build (VisualGDB-5.6.109.4769.msi) that supports the new Python environment layout.
