Forum Replies Created
-
Posts
-
Hi,
This looks like an incompatibility between valgrind and your kernel and not something directly caused by VisualGDB.
As far as our support goes, we can explain how VisualGDB launches valgrind and what modes it uses, however we would require an active license for that.
No problem. Please let us know the email address associated with your license so that we could link it to your support profile.
Hi,
Please do not manually copy any directories without understanding what causes the underlying problem. This only entangles the issue further and makes it harder to troubleshoot.
You can try exporting the ESP-IDF configuration command used by VisualGDB to a batch file as shown here. If the batch file shows incorrect IDF_PYTHON_ENV_PATH value, please let us know and we will look into it.
If the value looks correct, and ESP-IDF still doesn’t work, it could be a bug in ESP-IDF. Please consider reporting it to Espressif. If they suggest a configuration command line that fixes the problem, we can help you configure VisualGDB to use it instead.
Hi,
It looks like the project is not fully loaded, but VisualGDB doesn’t show the correct error message. Please make sure the Solution Explorer does not show the error icon next to the CMake project icon.
We have also updated the error reporting on our end, it will now correctly show “cannot locate the ‘flash’ target” instead of “object reference not set”.
Hi,
Please see the following page for more details: https://visualgdb.com/documentation/espidf/#python
Thanks for sharing this. This happens because “del” is not a separate executable, but is rather a built-in command of cmd.exe. If you don’t want to use a temporary batch file, you can also do this:
Command cmd.exe Arguments /c del […] Hi,
This looks like a bug in the SSH server.
The SSH protocol indeed allows running commands either with or without a PTY and both modes have different semantics. Running programs with PTY allows sending special events like Ctrl-C or wrapping the output to fit the terminal. However, it breaks processing of raw binary data, and forces many commands to assume interactive mode (i.e. they would ask for clarification instead of just returning an error code).
Based on what you have described, it looks like the non-PTY mode on the SSH server is broken.
VisualGDB can run commands in both modes, however it highly depends on the context. Forcing it to run everything with PTY would randomly break things like sending files using tar (that will try to interpret escape sequences inside binary data) or make completely unexpected commands hang with something like “press enter to see the next page” where VisualGDB totally doesn’t expect it.
A better option would be to try building the debug version of the SSH server from sources, run it under GDB, and see why it hangs without the PTY. You may need to patch the server code, or change something in the kernel configuration to accommodate it. If you wish, we could book a consulting session at our consulting rate and help you get this working via Zoom or other screen sharing tool.
Hi,
It doesn’t look like anything specific to VisualGDB, but rather the ESP32 chip itself is raising some kind of exception.
You can try checking the exact context (address/instruction where the stop is reported, and any output from OpenOCD or via the serial port).
Hi,
The -Wno-dev could be added to CMake command line via VisualGDB Project Properties -> CMake Project -> CMake command.
That said, we have looked into it and replaced exec_program() with execute_process() as recommended by CMake. We initially used exec_program() because of a CMake bug with quoting, but we ran some additional tests and managed to find a workaround that works. Feel free to update to this build: VisualGDB-6.0.4.5135.msi
Hi,
The 20-line limit in tooltips is by design to prevent them from filling the entire screen if VisualGDB attributed too many comments to the function declaration. You can easily change it via Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Tooltip line limit.
The excessive empty lines were indeed due to a bug. We have fixed it in this build: VisualGDB-6.0.4.5135.msi. We also added a setting (Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Condense function summaries) that allows removing extra lines between function argument descriptions, “returns” part and other similar blocks (requires reopening the project).
The </param> and </summary> should work the same – VisualGDB would trim the empty line at the end, and re-insert it on a higher level (between different parameters and different high-level blocks like summary or returns). If you meant something else, feel free to provide more details and we will look into it.
Hi,
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Hi,
You can manually install the toolchains to different directories, select “import by locating gdb” and point VisualGDB to the toolchain.xml files instead of gdb.exe (ESP32 has a very special toolchain layout, so the usual detection logic indeed won’t work).
This has been fixed in VisualGDB 6.0 – the “import” link now mentions toolchain.xml explicitly.
Hi,
Last time we checked, it requires the same toolchain as v5.1, so you can simply install it into it via the ESP-IDF release selector.
We will eventually release another toolchain that includes it out-of-the-box, but since the current toolchain works just fine with one very straight-forward extra step, it’s not a very high priority.
Update: We have released an updated toolchain with ESP-DF 5.2 included. You can download it here: https://gnutoolchains.com/esp32/
