Forum Replies Created
-
Posts
-
Hi,
If the linker did not generate the ELF file, there isn’t anything for VisualGDB to analyze. You can try patching the linker script to temporarily increase the RAM size so that the linker won’t fail, and then use Embedded Memory Explorer.
Hi,
It looks like you have specified invalid settings at some point. Unfortunately, it’s impossible to suggest anything meaningful without knowing what exact settings you have used.
Please try creating a new project from scratch, ensure that it builds, and then try changing one setting at a time until the problem triggers. Once you can reproduce it, please share a screenshot of the exact setting you changed and we will try to suggest a workaround.
Hi,
Normally the first header file should just include the second one. As long as both header files have a #pragma once, it should work just fine.
Another option would be to explicitly open the header file in a context of a .c/.cpp file that includes both of them in the correct order. You can do it via the navigation bar in the new VisualGDB 6.0.
Hi,
The actual FLASH programming logic is defined by the underlying SDK or Arduino platform. VisualGDB merely runs the programming command line defined by it.
If you can program FLASH from some other IDE or via command line without pressing the button, it could be a VisualGDB bug (e.g. some command-line option gets lost). If not, it’s a limitation of the platform you are using.
Hi,
If you suspect this is a bug of VisualGDB, you can try uninstalling the latest version and installing an older one here. If this fixes the problem, please let us know the version that works vs. the version that doesn’t.
If this doesn’t help, please try creating a new project from scratch and check if it works. If yes, you can try comparing the project files between the 2 projects. One of the settings that is different is likely causing the issue.
According to our records, we have replied to your inquiry with the details on the academic license purchase.
Hi,
This issue is different from the other thread (hence, we moved it to a separate one) and comes down to a bug in the ESP-IDF selector. After updating the toolchain and refusing to download the old (incompatible) ESP-IDF, VisualGDB should normally have shown the old ESP-IDF version in Project Properties, letting you select the new one, but it was instead showing just the new one, despite still referencing the old version.
We have fixed the issue in this build: VisualGDB-6.0.101.5152.msi. It actually includes 3 fixes:
- Suggests updating ESP-IDF reference to the one shipped with the new toolchain
- If refused, allows switching it manually via GUI
- When changed, clears the temporary files next time the project is loaded or built
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.
