Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
We have just added support for this to the final VisualGDB 5.3 (MSBuild projects only). Simply use the VS project properties (not VisualGDB Project Properties) to add the system include directories to your project.
support
KeymasterHi,
Looks like we missed it with our built-in visualizers. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.11.1837.msi
support
KeymasterHi,
Older version of CMake could have contributed to this indeed. Either way, if you run into this again, feel free to let us know more details and we will help you troubleshoot this.
support
KeymasterHi,
Thanks, the toolchain references look correct. Could you please try attaching the screenshot of the error along with the %LOCALAPPDATA%\VisualGDB\FindToolchain.props file? This should show what exactly is VisualGDB looking for and what toolchains are installed.
October 4, 2017 at 05:06 in reply to: What is this? Why does it always take so long? (20+ seconds) #12576support
KeymasterHi,
Thanks for verifying your support status.
It looks like the gdb executable is either hanging while VisualGDB is trying to execute initial commands, or the communication between VisualGDB and gdb is broken.
Please try enabling the gdb logging via VisualGDB Project Properties -> Advanced GDB Settings, then reproduce the problem, cancel the session and view the gdb log.
Do you see just one ‘-data-evaluate-expression’ command or multiple commands sent rapidly? If it is just one command, please try running gdb manually using the command line shown in the log and re-running the same commands. Does this trigger the gdb hang?
October 4, 2017 at 05:02 in reply to: Cross-compiling OpenCV with Advanced CMake for Raspberry Pi #12575support
KeymasterHi,
Please use the VisualGDB Project Properties to synchronize the toolchain sysroot.
support
KeymasterHi,
Strange, com.visualgdbm.arm-eabi is a toolchain ID, not BSP ID. Could you have accidentally edited the project files manually and confused some settings? Either way, does creating new projects with the toolchain/BSP work?
If yes, could you please compare the ToolchainID tags in the working vs. non-working projects (in .vgdbsettings files as described here)?
support
KeymasterHi,
Just to double-check, are you checking the “use the advanced CMake Project Subsystem” checkbox? If you are not sure, please try attaching a screenshot of the Solution Explorer in your project and we can check if this looks like the advanced CMake subsystem is active.
October 2, 2017 at 23:46 in reply to: What is this? Why does it always take so long? (20+ seconds) #12567support
KeymasterHi,
This could be caused by some toolchains-specific or connection-specific issues. We can help you troubleshoot this if you could let us know the email associated with your license so that we could verify your support status.
support
KeymasterOK, we have added support for running custom shortcuts in the background to the final release of VisualGDB 5.3.
support
KeymasterOK, we have fixed the issue with uploading imported project contents on the first build in the final release of VisualGDB 5.3.
support
KeymasterOK, we have added this to the final VisualGDB 5.3 release.
If a manually executed command shows “Loaded symbols for” as a part of its output, VisualGDB will automatically re-query the call stack and update the relevant Visual Studio windows.
support
KeymasterHi,
The “jtag status contains invalid mode value – communication failure” message usually indicates a wiring error. Lowering the JTAG frequency or enabling “connect under reset mode” might help.
If not, please try a different board. Wiring problems are often intermittent and can get triggered semi-randomly.
support
KeymasterHi,
For ARM devices the best supported JTAG/SWD debugger would be Segger J-Link. It costs more than low-end debuggers, but comes with its own low-level gdb stub that is actively maintained by Segger, tested with many devices and explicitly supported. Low-end debuggers like Olimex ARM-USB-OCD-H with OpenOCD are also quite reliable, although require some additional initial setup for some devices. Most of the issues you observed (like intermittent FLASH programming, random stops, inability to unwind frames, etc.) are specific for ESP8266/ESP32 simply because they have been figured out on ARM 10-20 years ago and Espressif didn’t have a chance to fix them yet.
Specifically for CC3200, debugging is reliable and works out-of-the-box, but programming the external FLASH memory is tricky and requires 3rd-party tools. For CC3220, OpenOCD has not been fully ported yet, so debugging it involves the proprietary TI XDS gdb stub, that is somewhat buggy, although we have customers successfully using it and can help you set it up if you decide to use it as well.
For ESP32 there is no 3rd-party tool ecosystem, so the Espressif OpenOCD port is the only way to debug their devices (ESP8266 also supports debugging over UART using a software gdb stub that runs on top of your software, but it has not been ported to ESP32 yet).
support
KeymasterHi,
It is hard to say why deleting the toolchain directory did not help before. Most likely some combination of installing different toolchains and VisualGDB versions left some files open and they were not deleted (e.g. if you had some header files open in Visual Studio, they would not be deleted). If you ever encounter this again, please let us know and we will re-investigate.
Regarding the debug issues, looks like your OpenOCD settings specify the target twice. Please try removing the second definition as shown below:
If stable debugging is the primary goal, we would recommend trying out CC3200 or other ARM-based chips. Espressif is doing a great job at offering superb functionality at a very low price, however they achieve this through not relying on the ARM core with a stable and reliable ecosystem of tools, but instead using a less popular Xtensa core and re-creating many tools from scratch. Given how popular their devices are, they will most likely polish all the rough edges relatively fast, however currently many of the ESP8266/ESP32-related tools are unstable.
We try to include workarounds for known issues and offer out-of-the-box setup and intuitive GUI, however resolving low-level communication issues between the 3rd-party tooling and the 3rd-party chip is unfortunately something beyond what we can offer as part of our products, sorry.
Attachments:
You must be logged in to view attached files. -
AuthorPosts