[support]

Hi,

Sure, this is already supported via the Visual Watch plugins. You can use the Debug->Visual Watch command to display arrays as graphs or images.

You can also create your own Visual Watch plugins to cover the cases not supported directly. E.g. you can fork our ImageWatch plugin and replace the version in “C:\Program Files (x86)\Sysprogs\VisualGDB\VisualWatchProviders” file, or place it under a different name to the same directory, or under %LOCALAPPDATA%\VisualGDB\LiveWatchProviders.

[support]

Hi,

You should be able to get it working by using the 3-machine setup shown here. You would need to import the custom RISC-V toolchains as a Linux-to-Linux cross-toolchain, disable the automatic deployment tests (you can configure to deploy the project to the same machine), and then override the debug setup.

As far as VisualGDB will be concerned, it will be a Linux-to-Linux project with a completely custom deployment and debugging sequence, so IntelliSense, build error messages and everything else related to build will work out-of-the-box.

To get debugging working, you would need to decide where do you want to run OpenOCD (or another similar program) and where to run GDB. E.g. you can add a custom pre-debug action to copy the built executable to the Windows machine, and then run both OpenOCD and GDB there. Or you could run OpenOCD on the Windows machine, and connect the gdb running on the Linux machine to it.

You can find some pointers and examples on this page; if you need further help, please make sure you can debug everything via command line, and share the details about your manual debugging setup, and we will help you configure VisualGDB to replicate it in the IDE.

 

[support]

Hi,

It mostly depends on what the device vendors do. VisualGDB supports FreeRTOS and ThreadX out-of-the-box (e.g. you can create a project from the wizards) because most device vendors provide FreeRTOS-based and ThreadX-based samples with their SDK, so all we need to do on our side is wrap these samples. If we see more device vendors provide out-of-the-box samples for Zephyr, we will certainly integrate them into VisualGDB.

So far, out of all major vendors, Zephyr is used by the nRFConnect framework, and VisualGDB supports it well. You can create projects via the wizards, VisualGDB will show the thread state via Zephyr thread plugin, etc.

If you want to use Zephyr with devices where the vendors don’t provide the samples, you can always setup the project manually. As far as VisualGDB is concerned, it’s just another CMake-based project, so you will be able to build and debug it as usual. You may need to adjust the thread plugin to accommodate a different stack layout, but that’s precisely the reason we publish sources for our RTOS integration plugins – so you can tweak them for use cases that are not directly supported out-of-the-box.

[support]

Hi,

VisualGDB does not update the system-level variables in order to avoid interfering with other tools. Instead, it sets them for just the process it’s launching to configure and build the project.

You can actually dump the configuration and build command lines to batch files, that show all the environment set by VisualGDB, and can be executed manually in order to simplify troubleshooting things. See this page for details.

If changing the variable globally fixed the project, it could have been hardcoded somewhere else (e.g. by editing the Python scripts) and the value set by VisualGDB was conflicting with it. If in doubt, we always suggest doing a clean toolchain installation, using a clean Python environment and a clean ESP-IDF checkouts. We test them before releasing our toolchains, so they should work just fine out-of-the-box.

[support]

Hi,

Thanks for reporting this, looks like a bug on our side. Please try this build: VisualGDB-6.0.4.5003.msi

[support]

Hi,

Looks like something about your project breaks the linker. As far as VisualGDB is concerned, it starts the build, sees the error message and reports it as expected.

You can try enabling verbose mode, getting the exact gcc/linker command lines, and asking in the binutils mailing lists if you need further help.

[support]

@hikingDev

Thanks, the assemblies on your machine do match our test setup, however, it looks like you are using a couple of extra VS extensions that could be interfering with the WPF.

Please try disabling all other extensions via the Extensions->Manage Extensions command in Visual Studio. If it solves the problem, please try checking if enabling a particular extension triggers the problem, so that we could try installing it on our side and reproducing this.

Edit: for what it’s worth, you can try this build: VisualGDB-6.0.3.4994.msi. It has RemoteHostSelector.Mode renamed to RemoteHostSelector.HostSelectorMode, so if the old name was triggering some strange name collision, it should not happen anymore.

[support]

Thanks for confirming this. It looks like a rather strange assembly load issue. Please try this build: VisualGDB-6.0.3.4993.msi

If the problem persists, please click Help->About VisualGDB while holding the Shift key. The About window will show one extra button called “Troubleshoot Assembly Errors”.

Once you click on it, VisualGDB will generate a detailed report showing possible conflicts. Please attach the report together with the updated call stack from the error message, and we will look further into it.

[support]

Hi,

Based on a quick look, the CCOUNT is indeed not mapped to memory, so reading it would involve patching the ESP32 OpenOCD to allow reading it via special command.

If you would like to get it working, we can offer 2 options:

1. You can try convincing Espressif to add an OpenOCD monitor command for reading CCOUNT (it should be runnable via gdb), or implementing it yourself. If you can get it working, we can help you configure VisualGDB to use it, as long as you have an active VisualGDB license.
2. If we see sufficient interest in this feature from other paid users, or if someone orders it as a custom feature, we can do the OpenOCD patching on our side. If you would like to get a quote for this as a custom feature, feel free to contact us via the support form.

 

[support]

Hi,

Sorry, had a typo in the path. The correct path to DWT.xml would be C:\Program Files (x86)\Sysprogs\VisualGDB\TimestampProviders\DWT.xml.

[support]

Hi,

Sorry, it’s hard to suggest anything definitive based on the description you provided. Please try attaching screenshots of the entire uncropped Visual Studio window showing the project you created, the menus you are using to add files, and the folder that is shown in the “Open file” dialog, and we can try to suggest how to alter it.

[support]

Hi,

This is correct. The chronometer relies on the DWT_CYCCNT register, that is only available on ARM Cortex cores.

The Xtensa cores have a similar register called CYCCNT, so you can try copying the %VISUALGDB_DIR%\DWT.xml file under a new name and changing it to use the Xtensa CYCCNT address, but we have not tested it on our side and cannot guarantee that it will work.

[support]

Hi,

A reasonable strategy would be to get it working outside VisualGDB first (e.g. with PuTTY), make sure it works the way you expect it, and then describe your setup so that we could help you replicate something similar in VisualGDB.

[support]

Thanks for verifying your license. This problem would normally be caused by a bug in the .Net image rendering logic that is triggered by some color profiles, although we have fixed it in the latest 6.0 branch.

You can try reverting to the default color profile via Windows Color Management -> Advanced -> Device Profile = System Default.

If it doesn’t help, please try creating a new project selecting the “full-custom” debug mode in the wizard. Does it show the Debug Settings page correctly? If yes, does switching to OpenOCD immediately show an exception?

[support]

Strange. Could you please share a screenshot of the Help->About VisualGDB window?

[Author]

Posts