[support]

Thanks for sending us the screenshot (we removed it for privacy). It looks like VisualGDB is initialized correctly, so the problem is likely caused by something else.

Please try the latest development build: VisualGDB-5.5.8.3770.msi

If the problem still persists, please try checking if there is a specific project type that triggers the problem. If yes, please share the steps to reproduce it from scratch (i.e. from creating a new project) and we should be able to fix it.

[support]

Hi,

This looks like a corrupt installation. Could you please share a screenshot of the Help->About VisualGDB window so that we could check what is going on?

[support]

Hi,

It looks like your support period has expired. Please kindly renew it here and we will be happy to help you resolve this.

[support]

Thanks for pointing this out. We have updated the tutorial.

BTW, feel free to try out the new Advanced CMake subsystem for Embedded Projects (VisualGDB-5.5.8.3770.msi). It supports multiple targets per project (i.e. bootloader + main target) and allows referencing target outputs from other targets without the need to modify any files manually.

It will be included in the upcoming v5.5 RC1 and we will publish more documentation on it soon.

• This reply was modified 4 years, 11 months ago by support.

[support]

Thanks, just one more question then. Did the problem ever happen on a recently started VS instance (i.e. NOT after a long period if inactivity)?

[support]

Hi,

One quick question: does the problem always happen after you let Visual Studio instance (or MSBuild) run for a long time idling, and then do a build?

[support]

Due to some internal changes in the new toolchains, they are not fully compatible with VisualGDB 5.5 Preview 7. We are running some final tests on them and expect to release the v5.5 RC1 around next week.

Update: you can try our new R7 toolchain. It includes both ESP-IDF 4.1 and 4.2 and works out-of-the-box with the VisualGDB build linked above.

• This reply was modified 4 years, 11 months ago by support.

[support]

Hi,

As long as you use the TinyEmbeddedTest framework, you can set the “Redirect printf() to Test Output window” option in the Test Framework Properties and the output will then appear under the test results (Show Additional Output link). That said, make sure you don’t have multiple conflicting options enabled (see this page).

[support]

Hi,

We have briefly retested the latest ESP-IDF 4.1 with our 8.2.0-r6 toolchain (requires this build: VisualGDB-5.5.8.3769.msi) and it worked out-of-the-box (you need to use the ESP-IDF checkout selector to clone the 4.1 release explicitly).

However, it looks like the 4.2 release is now broken due to unresolved Python dependencies. We will look for a way to ship any extra dependencies together with the toolchain and will publish an update once it works reliably. In the meanwhile, you should be able to replicate the setup on your side by using the toolchain and VisualGDB build mentioned above.

[support]

Thanks, we have updated the definitions on our side and will include them in the next release of the OpenOCD package.

[support]

Hi,

Please try checking the output window (View->Output) for the complete build log. It should contain more information about the error, explaining what exactly went wrong.

If you are not sure, please share the entire log and we will help you understand it.

P.S. Please consider using MSBuild or Advanced CMake instead of GNU Make. It is much better integrated with the VS GUI and will have a much lower chance of random failures due to misaligned settings.

[support]

Thanks, this might be related to a glitch that was recently fixed on our side. Please try this build: VisualGDB-5.5.8.3769.msi

[support]

No problem, please see this page for more details.

[support]

Hi,

We haven’t tested the tumpa adapter directly, but for the directly supported interfaces, VisualGDB can handle multiple instances automatically. Please try locating the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\QuickSetup\interfaces.xml file and search for Olimex ARM-USB-OCD-H.

You can create a similar entry for tumpa, specifying:

• USB VID/PID/interface
• OpenOCD script file
• OpenOCD command for setting the serial number (should be ftdi_serial, same as for Olimex)

You will also need to update the EDP.XML file (search for Olimex ARM-USB-OCD-H again).

Once you edit the files and restart Visual Studio, Tumpa devices will appear in the “USB Devices” view inside Debug Settings, and VisualGDB will automatically pass the serial number to OpenOCD when it detects multiple instances.

Feel free to attach the edited files here (please pack them into a .zip or .7z file) and we will ship the changes together with the upcoming OpenOCD updates.

[support]

No problem, please try this build: VisualGDB-5.5.8.3769.msi

[Author]

Posts