Forum Replies Created
-
Posts
-
Hi,
As you have pointed out before, you can disable the suggestion popups via Tools->C/C++ (VisualGDB)->advanced->Code Completion->Suggest names while typing.
You can also try setting Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Smart Suggestion List GUI to VS2019+ Native that is somewhat slower than the VisualGDB-provided one, but will work better on high-DPI displays.
You can disable the Code Explorer (Outline and Globals views) by unchecking the “Show window on startup” setting as shown here.
Based on our experience with ESP32, not all combinations of toolchains and SDKs work together well. Espressif frequently releases updates to the toolchains, ESP-IDF and ESP-ADF, where we pick them up, run a few basic tests and release ready-to-use packages.
Sometimes, these releases contain bugs that are addressed later (e.g. the latest ESP-IDF 4.3.1 breaks projects using mbedtls, and the workaround is to cherry-pick a specific commit from another branch). As Espressif typically fixes the issues relatively fast, we leave it up to them and stick to shipping ready-to-use snapshots of their most recent public releases.
We have designed VisualGDB to be very flexible, so that it can be used with any combination of the tools that works otherwise. If you have a specific version of ESP-ADF and toolchain that work together, you can merge them into our toolchain by replacing the contents of the tools and esp-adf directories, and updating the paths in toolchain.xml. VisualGDB will pick up these paths and will produce exactly the same results as your Eclipse-based environment does, because it will run exactly the same tools with exactly the same arguments. This might require some minor troubleshooting, but since VisualGDB allows dumping the exact command line it uses for building, you can very easily troubleshoot issues by comparing it against another command line that works just fine.
Hi,
The ESP32 toolchains are provided by Espressif. We merely pick up the stable releases, bundle it together with the latest stable ESP-IDF and run a few basic tests. If you would like to know the difference between 2021r1 and 2021r2, please contact Espressif.
You can download an equivalent of the 2021r1 toolchain from Espressif here: esp32-gcc8.4.0-r3.exe
Hi,
idf.py is normally included in the toolchain (e.g. sysgcc\esp32\esp-idf\v4.3.1\tools\idf.py and sysgcc\esp32\tools\idf-exe\1.0.1\idf.py.exe). The easiest way to run it would be to dump the project configuration command to a batch file and replace the actual “cmake” command with cmd.exe. This will run the command prompt window with the same environment that VisualGDB would use for cmake (that should be sufficient for most tools). You can then try running idf.py from that window.
Based on the description you provided, it looks like a bug in ESP-ADF that might be triggered by a specific toolchain. If you can confirm that it works just fine in the Eclipse environment (i.e. the generated file can be FLASHed successfully), please try downloading the same toolchain version from our download page and installing ESP-ADF there.
You can also simply replace the contents of the esp-adf directory inside the toolchain with the version that works from Eclipse. If it doesn’t help, you may need to also replace the tools in the tools subdirectory, and update the paths to them inside toolchain.xml.
Hi,
The “Analyzing references” stage only affects advanced recoloring of the source file, finding references, etc. You can indeed enable lightweight references analysis if you would like to speed it up.
Code suggestions and go-to-definition use a different mechanism that does not involve the “Analyzing references” part.
The debug log looks like the delay comes from gdb and not from VisualGDB itself. Hence, it will affect any debug session that is using gdb and cannot be reduced on the VisualGDB side.
Hi,
VisualGDB uses the open-source OpenOCD tool to handle hardware-level debugging aspects. The support for ST devices in OpenOCD is contributed directly by ST, so it typically works quite well with most of the boards, including the Nucleo-144 ones.
Hi,
The IntelliSense-level precompiled headers are different from the GCC precompiled headers. The please make sure you explicitly configure Clang IntelliSense to use pch.h as a precompiled header file as shown in step 11 of this tutorial.
The slow debugging performance likely comes from gdb itself. You can verify it using the timing view in the GDB session window and you might be able to speed it up by using symbol indexes.
Hi,
Good to know the copying works. As mentioned before, KGDBoE is highly experimental and will likely need to be ported for your board/kernel version. Please try building it manually first as shown in this tutorial. Once you resolve the build errors and get it to load, you can simply connect VisualKernel to that machine. It will recognize that KGDBoE is already loaded, and will connect to it.
Thanks for confirming this. If the files can be uploaded manually, please try opening Tools->VisualKernel->SSH Host Manager, selecting your SSH connection and changing the following parameters at the bottom of the “SSH Connection” dialog (please try changing one parameter at a time):
- Emulate SCP file transfers with ‘cat’
- Transfer folders using: file-by-file SCP
This will change the low-level method used by VisualKernel to upload the files, and should work around the issue.
If it still doesn’t help, please let us know and we will send you a special diagnostic build with additional logging.
The error message means that the target did not accept the request to upload the file. Please try uploading files manually to that directory by running the scp tool from another Linux machine. If the upload files, something about your SSH server configuration is preventing file uploads. Enabling the diagnostic logging in the SSH server settings and checking the logs should normally point to the root cause.
Also please note that KGDBoE (debugging over Ethernet) is highly experimental. It may not work with your Ethernet hardware, or can work unreliably. You can try it out by building KGDBoE manually as shown here. In general, we recommend using JTAG to debug custom embedded boards. It requires additional wiring, however works much more reliably compared to KGDBoE. You can find a tutorial on debugging Raspberry Pi via JTAG here, and we can always help you figure out the correct wiring and OpenOCD settings for your specific board via our consulting service, if you want to get it working ASAP.
Please try checking whether the project built via command line actually uses the correct partition table file (i.e. whether it flashes successfully via idf.py flash). If the file works just fine (e.g. you can edit it manually and the changes are applied) and the only issue is that the “Partition table” item in Solution Explorer is not working), we should be able to fix it. If the file doesn’t work when the project is built outside VisualGDB, the issue is not on the VisualGDB side, and VisualGDB cannot fix it automatically.
Hi,
There is no special command in VisualGDB to copy/move the files, however you can always copy the files using Windows Explorer first, and then specify the new location in the VisualGDB Project Wizard.
No problem. If the project has loaded successfully, the command would be “Reload CMake project”.
The Eclipse-based environment might be using a different version of ESP-IDF, or a different toolchain, that would indeed produce different results. Please try reconfiguring and building the project via the command line exported from VisualGDB. If it works differently from the build from Eclipse, you can try comparing the 2 command lines, or the SDK versions, so see what exact part is causing the difference.
Hi,
Please try updating to the latest VisualGDB 5.6. If the problem persists, please let us know the updated stack trace.
Hi,
The documentation indeed refers to copying the UF2 file. We are not aware of any other ways to program the Raspberry Pi Pico memory without the SWD pins.
On the VisualGDB side you can automate copying of the UF2 file by creating a custom shortcut (simply use “cmd.exe /c copy …” command to copy the UF2 file to the device), however you would still need to press the BOOTSEL button and reset the device in order to enter the bootloader, unless you can find a programmatic way to do it from your firmware.
