[supportKeymaster]

Hi,

This is a known limitation of CMake. It indeed does not report the contents of interface targets via the mechanism used by VisualGDB.

Please consider using object libraries instead – they work similar to interface targets, but their contents is actually shown.

[supportKeymaster]

Hi,

VisualGDB has its own easy and intuitive mechanism for custom steps. You can use the “Custom build steps” page of VisualGDB Project Properties to define a variety of different steps using convenient GUI.

Note that this feature is available starting from the Custom edition.

[supportKeymaster]

Good to know you managed to reproduce it. One thing, issues like this could be caused by bugs in the network stack (packet with the command from VisualGDB gets lost and is never resent). If the issue happens intermittently over SSH, but never locally (e.g. in an xterm window), it could be caused by the network rather than the gdb executable.

[supportKeymaster]

Hi,

This message means that your gdb debugger is taking too long to process the variable evaluation command issued by VisualGDB. The delay does not come from the VisualGDB side and it caused by the gdb itself.

If you would like to find out what is causing it, please consider building a debug version of your gdb executable and stepping through it once you reproduce the issue.

[supportKeymaster]

Hi,

According to the gdb log, it actually manages to stop in main() before stopping in the unknown location:

C++

[ 13421 ms] *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={addr="0x400d4bab",func="app_main",args=[],file="../../../main/blink_example_main.c",fullname="C:\\Users\\Jens\\Documents\\ESP32\\Solutions\\EmbeddedSolution1\\EmbeddedProject1\\main\\blink_example_main.c",line="74",arch="xtensa"},thread-id="1",stopped-threads="all"

1

[   13421 ms] *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={addr="0x400d4bab",func="app_main",args=[],file="../../../main/blink_example_main.c",fullname="C:\\Users\\Jens\\Documents\\ESP32\\Solutions\\EmbeddedSolution1\\EmbeddedProject1\\main\\blink_example_main.c",line="74",arch="xtensa"},thread-id="1",stopped-threads="all"

Please try removing the WaitForSysprogsDebugger() function and using F10 instead of F5 to start the debug session. It will automatically stop the program at the beginning of app_main(), so you will be able to step through it and see which parts of the program work.

[supportKeymaster]

Hi,

Just to double-check: you are observing that unchecking the “build” checkbox in Configuration Manager for a particular project moves the unit tests from it into the “external” category, rather than hiding them as expected, correct?

[supportKeymaster]

Hi,

This could be a bug in OpenOCD, or something specific to a device (e.g. the firmware disabling the JTAG/SWD pins). The best way to troubleshoot it would be to break it down into smaller parts:

1. Try running OpenOCD manually. Check if you can read/write the memory at the end of stack using the mdw/mww commands.
2. If yes, try connecting gdb manually and running the “print *((void **)0x2001fffc)” command.
3. If it works, try manually running the gdb commands executed by VisualGDB (from the log file) to see which of them causes the memory to stop working. E.g. some part of the FLASH loader might interfere with the pins, clocks or other settings.

You can also try building OpenOCD from sources as shown here and double-checking what exactly happens when it tries to read memory, or run specific commands.

[supportKeymaster]

As we suggested before, you can try using Segger J-Link. It comes with its own software that supports more devices out-of-the-box compared to OpenOCD and include sits own support for low-level issues like this one.

If you are specifically looking for someone to get OpenOCD working with a specific example on a specific chip, unfortunately it is not something we could do without charging our consulting rate. Feel free to ask around on freelancing sites – perhaps someone can offer to do it at a lower rate. This is not specific to VisualGDB and does not rely on any VisualGDB-specific knowledge.

[supportKeymaster]

Hi,

Indeed, the custom build/debug steps, are shared between multiple project configurations. The easiest way to have run different actions depending on the configuration platforms is to use the “Reference a reusable action list” action with a variable-based path (e.g. $(PlatformName).vgdbxactions).

The user variable values are stored in per-user files (e.g. <Project>.<UserName>.user), so having them differ between platforms would cause conflicts. Instead, we would advise having the variables for all platforms defined together, and then using them depending on the platform, e.g.:

• The variable list defines DeployHostARM and DeployHostX86
• The ARM platform references $(DeployHostARM)
• The X86 platform references $(DeployHostX86)

If this doesn’t work, feel free to let us know more about your setup, and we will try to suggest a better layout.

[supportKeymaster]

Please note that VisualGDB is a productivity tool for software developers. It can make developers more productive by providing convenient GUI for common time-consuming tasks, and integrating various external tools into Visual Studio, so that they are always a few mouse clicks away.

We are able to offer VisualGDB at affordable price, because we focus on developing and supporting functionality that works the same way for multiple users, hence the development and testing effort is reused between multiple license holders.

We also receive a huge amount of inquiries asking to fix a specific broken project, help make the correct design choice, explain how a specific C++ feature works, or assist porting a library to a different platform. These inquiries require considerable effort to research and communicate the best solution. They do not scale between multiple users. I.e. helping one user solve this type of problem will not automatically help other users. It also does not help the same user avoid the same type of problem in the future. Hence, we are not able to address them within our regular support. If we included this type of help in our support, we would simply not have sufficient resources to provide it at the current license prices, or to allocate any resources to VisualGDB development.

We are happy to offer project-specific help via our consulting service per Zoom, TeamViewer or any other screen sharing service of your choice. We charge a fixed consulting rate for these sessions (billed in 1/2-hour increments), and are happy to solve any problems our users encounter. The rate includes a detailed follow-up email at the end of the session, that includes an overview of the used techniques and a summary of solved problems and future recommendations.

Alternatively, please consider browsing our documentation and tutorials. Our documentation lists most VisualGDB settings, and the tutorials show how to use VisualGDB for in many real-world scenarios. Our technical support is limited to issues in VisualGDB itself, that can be reproduced from scratch per our problem reporting guidelines (i.e. do not depend on external projects that can potentially contain errors).

[supportKeymaster]

Hi,

The i.MXRT devices might require additional initialization in order to get some parts of the memory working. MCUXpresso would do it automatically (since it has proprietary device definitions), while the OpenOCD tool you are currently using with VisualGDB may require scripting it manually. Another option would be that some build-time options are set incorrectly.

In general, you can try using Embedded Quick Debug on the ELF file produced by the MCUXpresso IDE. If it works fine with VisualGDB, the issue is due to the build settings. You can try dumping the memory layout of both images with objdump and comparing them to see what could be causing the difference.

If debugging the image produced by MCUXpresso IDE is not working, you may need to run some additional initialization on the OpenOCD level. You can try issuing the “monitor mdw” and “monitor mww” commands via the GDB Session window to read/write various memory addresses directly via OpenOCD, and use it to understand what memory regions are turned off, and enable them by writing the device configuration registers.

Another option would be to try Segger J-Link with the J-Link software. It provides better out-of-the-box support for many devices, compared to OpenOCD, and VisualGDB works with it just fine.

[supportKeymaster]

Good to know it works.

There was indeed a bug preventing VisualGDB from turning on the SSH command line limit mitigation, and we fixed it in this release. Also the 131K shell limit should no longer be a problem with GoogleTest, as the long GoogleTest command are now passed via a command file that is directly read by the GoogleTest framework, completely bypassing the shell (similar to GCC response files).

Regarding the test discovery, it looks like it’s caused by some combination of VS test display rules and your project configuration. Please try reducing the problem to something that can be reproduced from scratch (i.e. a solution with 2 freshly created projects). Once you can point to specific settings triggering it, we should be able to suggest a workaround or release a hotfix.

[supportKeymaster]

Hi,

Please contact Espressif for information on compatibility between specific ESP-IDF releases and toolchain versions.

[supportKeymaster]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[supportKeymaster]

Hi,

The regular OpenOCD GUI is indeed optimized for running OpenOCD locally – it can automatically find the supported JTAG/SWD probes, install drivers, locate device scripts, etc.

If you would like to run OpenOCD remotely, please try selecting the “Full-custom” debug method instead of OpenOCD. It allows specifying arbitrary target connection commands, and will not attempt to do anything beyond what is explicitly configured.

[Author]

Posts