Forum Replies Created
-
Posts
-
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/
No problem. We will monitor the feedback from other users and will consider adding a warning if others encounter the same issue.
Hi,
The heap view in Live Watch is indeed designed for much smaller heaps that would typically fit into the on-chip SRAM and can be polled at a reasonable rate. Reading out 16MB of SDRAM over a typical JTAG connection would indeed take several minutes, and would not be really practical.
Hi,
Sorry, it doesn’t look like any known issue. Most likely, some file somewhere got corrupt and is interfering with IntelliSense.
Our best advice would be to reset the environment (toolchain, ESP-IDF) and try creating a new project from scratch. If the problem doesn’t reappear on the new project, try comparing the project files between the working and non-working projects to pinpoint the setting that could be causing this.
Hi,
This is really something to check with the ICWYU developers. If they are willing to make it compatible, we can provide a public interface for their extension to query the VisualGDB project structure (it’s actually rather straight-forward on our side – just a list of files and corresponding Clang flags) and help them get it working. If not, it’s really not up to us, sorry.
Hi,
You can configure custom pre-build steps via VisualGDB Project Properties -> Custom Build Steps.
As for the command line, it’s something for you to figure out. VisualGDB can run arbitrary command lines at different times during the build as configured via VisualGDB Project Properties, but it’s up to the user to make sure these command lines make sense and work as expected.
