[support]

Hi,

Sure, you can download various packages manually here and install them via Tools->VisualGDB->Manage VisualGDB Packages.

BTW, if your corporate network uses a proxy server and denies direct connections, you can configure VisualGDB accordingly via Tools->Options->VisualGDB->General->Other->Proxy Server.

[support]

Hi,

The version of CMake installed by VisualGDB is 100% compatible with the regular CMake. The only differences introduced by it are related to accurate reporting of the code model (e.g. various statements affecting each target’s CFLAGS) and to debugging (stepping through CMakeLists.txt files).

For projects built locally VisualGDB always tries to use our CMake fork, as it makes the settings editing GUI more accurate (VisualGDB can better locate and edit existing statements when you change target settings via target properties). Either way, we have added a setting to disable this behavior to the following build: VisualGDB-5.6.106.4647.msi. The new setting is located under Tools->Options->VisualGDB->CMake->Use pre-built CMake for Local Builds.

[support]

Update: we have just rechecked VisualGDB profiling with the latest mbed 6.16 and it worked just fine. We have updated the tutorial showing how to patch the mbed source to facilitate profiling.

If it still doesn’t work for you, please follow the instructions in our previous reply to carefully document every step you take when creating the project, and we will gladly point out the possible cause of the problem.

[support]

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.

[support]

Hi,

VisualGDB references toolchains using unique IDs and versions:

• Each project file contains a ToolchainID element with the toolchain ID and version
• VisualGDB matches it against a list of known toolchains on this computer (see this page) and automatically loads the correct toolchain

This mechanism allows having different toolchain locations on different machines while sharing the same project file between all users.

If you would like to check in your toolchain into the your repo, you can simply move the toolchain there, and then import it into VisualGDB on each computer (click the “locate existing toolchain” link in the toolchain selector and point it to the toolchain.xml file). VisualGDB will then automatically locate it using the usual ToolchainID reference.

You can also use the Team Settings to automatically install the same toolchain on multiple computers.

[support]

Hi,

The ESP32 projects (and other Advanced CMake projects) use a different structure of settings compared to the regular MSBuild/Make projects.

Please see this page for a detailed overview.

[support]

Hi,

According to our records, your license does not have an active technical support. If you believe it is a mistake, please contact our support via the contact form.

[support]

Hi,

The exact names and structure of the IRQ handlers slightly varies between different mbed versions.

In general, the thread_switch_helper callback is supposed to be called just before the mbed runtime switches the context to another thread, so the VisualGDB profiler could handle this event and update its internal structures accordingly.

If the version you are using does not have the SVC_ContextSwitch call, please try locating the logic responsible for loading the stack pointer (similar to SVC_ContextRestore on the screenshot in our profiling tutorial) and inserting the call to thread_switch_helper just before it.

Edit: we have just retested the VisualGDB profiling with the latest mbed release and updated the tutorial. As of mbed 6.16, the call to thread_switch_helper goes right after the SVC_ContextRestore label and needs to save/restore the LR register as well as shown in the updated tutorial.

[support]

Hi,

We have just rechecked the switching between the debug and release configurations and it worked just fine.

Most likely, you have changed some project settings to the values preventing VisualGDB from loading it.

Please try creating a new project from scratch and check if the problem persists. If not, please try comparing the settings between the 2 projects and eliminating the differences one-by-one.

[support]

Hi,

For CMake projects, the debugged executable path is automatically derived from the actual project structure. If you would like to debug arbitrary executables, we would advise using Quick Debug instead.

If you would like to have multiple debug configurations, you can try using the configuration/platform manager. Simply add a CMake-level variable in the configuration settings, and then check it on the CMake statement level (e.g. using the ${} syntax or in conditional statements) to produce different executables in different configurations.

VisualGDB will automatically pick up the correct executable based on the active platform.

If this is not what you are looking for, please let us know more what you are trying to accomplish, and we will try to suggest a better solution.

[support]

Hi,

Please refer to the following page for details: https://visualgdb.com/documentation/mefcache/

[support]

Hi,

This error means that gdb requests the device to read the memory at address 0x20050004 and the device responds with an error. The address would normally be computed by OpenOCD based on the debug settings (e.g. device script) and the ELF file produced by the mbed build.

The best way to troubleshoot it would be to recheck the device datasheet whether it’s a valid memory address (e.g. part of RAM). If it is, please double-check the OpenOCD debug scripts and settings for possible settings preventing memory reads from working. If it is not, please recheck the ELF file and the debug settings for possible hints pointing to the incorrect address.

[support]

Thanks for sharing this. It indeed looks like a change in ESP-IDF structure and not something VisualGDB would handle automatically. That said, if you do not want to edit the CMakeLists files manually, you can always specify the extra environment variables via the VisualGDB GUI as shown below:

Attachments:

You must be logged in to view attached files.

[support]

No problem, we have added a detailed documentation page explaining MEF issues: https://visualgdb.com/documentation/mefcache/.

If it doesn’t help, please share your observations (the logs mentioned on the page) and we will help you get it working.

[support]

Hi,

Sorry, it looks like something specific to your project or the gcc compiler rather than a VisualGDB-specific issue. If you would like to get generic programming help, please consider creating a question on StackOverflow instead.

[Author]

Posts