[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

Hi,

Please try updating to the latest VisualGDB 5.6. If the problem persists, please let us know the updated stack trace.

[support]

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.

[support]

Hi,

This looks like a bug in the ESP-ADF itself. Please try building the project outside VisualGDB as described here. If the problem persists, it is not specific to VisualGDB and likely requires a patch to ESP-IDF or ESP-ADF. If the problem only happens when using VisualGDB, please let us know more details and we will help you configure VisualGDB to replicate the results of the manual build.

EDIT: We have updated our ESP32 Documentation explaining the relations between ESP-ADF and ESP-IDF, and how they could cause this type or problems.

• This reply was modified 3 years, 10 months ago by support. Reason: added link to the updated documentation

[support]

Hi,

Thanks for providing us the additional details. It looks like you are using the older VisualGDB build that is indeed not fully compatible with the latest ESP-ADF.

We have just released VisualGDB 5.6 that addresses this issue, and introduces many new features. Please feel free to update to it.

[support]

Hi,

Thanks for the update. The delay between “Doing a CodeComplete run with minimal reparsing” and “Exporting parse results” is the time that Clang takes to parse the source file and determine the symbol referenced at the requested location.

Normally, it should take roughly the same time as the regular code completion (Ctrl-Space) does, that is typically under 1 second. If it takes longer, most likely, the precompiled headers or preambles are not working properly. We can help you get it working if you could check a few additional things:

1. Does the IntelliSense timing view (step 7 of the tutorial) show anything extraordinary? Could you share a screenshot of it?
2. Does code completion (Ctrl-Space) work faster that Go-to-Definition? Is the speed the same for unscoped completion (e.g. int main() { <HERE> }) vs. scoped completion (std::<HERE>)? Could you attach the snippets from the Clang IntelliSense log corresponding to the scoped and unscoped code completions?

[Author]

Posts