[support]

It’s not exactly a secret, but we constantly update planned feature priorities based on the feedback we get from users,  new releases of popular frameworks (and changes of framework popularity) and so on. E.g. we were originally planning to postpone the advanced mbed project subsystem to v5.5, however as the mbed popularity kept on rising, we decided to push it into v5.4. Hence the best way to learn about the latest VisualGDB features would be to follow us on Twitter and watch for the announcements of preview builds and new features.

[support]

Hi,

You can find the newlib-nano license here: https://github.com/32bitmicro/newlib-nano-2/blob/master/COPYING.NEWLIB

You can find a discussion on using gcc for building closed-source projects here: https://opensource.stackexchange.com/questions/334/can-i-develop-closed-source-software-with-an-open-source-development-environment

[support]

Thanks for the update. Unfortunately this one is tougher. It looks like OpenOCD does not know how to interface with the J-Trace version you have. Given that it uses a different driver with the regular Segger setup, it might not be backward-compatible (and hence compatible with OpenOCD) at all. You could try hacking our OpenOCD port to update the J-Link USB IDs, however this may not work if the internal protocol is different.

As a quicker solution, please consider getting an FT2232-based debug probe (e.g. Olimex ARM-USB-OCD-H). Since ESP32 relies on OpenOCD anyway, there will be no usability difference between the more expensive J-Link probe and a cheaper FT2232-based one when debugging ESP32 devices.

[support]

Hi,

Sorry for the delay. We have retested coverage report building with the latest VisualGDB 5.4R2 for cross-toolchains (using /runtests) and unfortunately could not reproduce this. Please double-check the environment variables you set (should be VISUALGDB_SHOW_DIAGNOSTIC_OUTPUT, not just SHOW_DIAGNOSTIC_OUTPUT).

The problem might be also related to the custom console command you are using:

Launching custom program console

Please try temporarily disabling it.

Finally, it looks like you are using the latest gtest framework with an older VisualGDB build (pre-v5.4R2) that might not be able to handle the test selection rules properly (we had to change them to fix incorrect handling of test names with multiple underscores). Please try updating to the latest VisualGDB.

[support]

Thanks for reporting this. The message is just the default text for the default E_FAIL code returned by Visual Studio when trying to start another build before the current build completes (target installation counts as a special build). It should indeed not have any consequences and we will consider replacing it with something more informative next time we redesign that part.

[support]

Hi,

Sorry, this looks like a question about the Nordic SDK capabilities, not about the VisualGDB features. Please try posting a question on the Nordic DevZone – you should be able to get support for Nordic-specific issues there.

[support]

Hi,

Yes, the ESP8266/ESP32 devices use a separate debug method package (%LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp32.core). Also as the Segger GDB stub does not support the ESP8266 and ESP32 devices, they use OpenOCD that only works with the WinUSB driver. Please try adjusting the edp.xml and QuickSetup\interfaces.xml files to reflect your device ID. Feel free to post the necessary modifications here and we will update our packages accordingly.

[support]

Hi,

Please check that you actually have write access to the location where you are trying to install it and that your antivirus is not blocking the toolchain installer. If nothing helps, please try downloading it manually from http://gnutoolchains.com/esp8266/ and run the installer in the interactive mode.

[support]

Hi,

This is normally something handled by the Segger GDB stub (VisualGDB launches it with the parameters you specify via settings and expects it to take care of the low-level JTAG interaction and provide high-level debugging information to gdb), so please check with Segger support if this is possible with their tools.

If not, you could try using OpenOCD instead. If secure JTAG is not supported by it yet, you could patch it (consider using our easy-to-build OpenOCD fork), wait for someone else to contribute the patch, or we could add it for you via our paid customization services.

[support]

Hi,

Until relatively recently, STM8 devices did not have a usable GDB debugger, so VisualGDB could not be used with them. Currently, it looks like there is an unofficial port of gdb and binutils (although you still need to rely on SDCC instead ofGCC), so you might be theoretically able to get it to work by following this tutorial. That said, we have not investigated this at all and cannot promise that it will work. We will try to do a quick research into STM8 around Q3 2019 and see if the available tools are sufficient to provide reasonable building/debugging experience.

Alternatively if you can confirm that the underlying tools are fully usable (and share details), we should be able to update VisualGDB to support STM8 out-of-the-box earlier.

[support]

Sorry, it is not possible to directly call a function that would need to run on a different device. Unfortunately, as this is not a VisualGDB-specific inquiry, but rather a generic programming question, we are not able to allocate resources to walk you through this as we have to focus on making our products better and helping users that are affected by VisualGDB bugs. For general programming questions, please consider creating a question thread on StackOverflow.

[support]

Hi,

Unfortunately it’s hard to say what exactly is wrong without knowing the details. Is the imported project using MSBuild, VisualGDB-generated Makefile, or a 3rd-party Makefile? Please also try isolating just one file compilation task (i.e. modify one file and count exactly how much time does it take during VisualGDB-controlled build vs. when running gcc manually). If you are using a custom Makefile, please modify it to start a cmd.exe instance in a new window (using the ‘start’ command) and then try running gcc or make from that window. If it also builds slowly, it could be caused by some environment variables inherited from Visual Studio.

It could also be helpful to temporarily disable your antivirus or trying to use a different disk, as buggy antivirus software or disk errors could cause seemingly random slowdowns.

[support]

Hi,

Sorry, the page inside SSH Connection Manager is called “host-wide settings” and you will need to create an entry for your host in order to configure the timestamp difference.

[support]

Hi,

In Visual Studio the include search paths need to be specified explicitly. Just adding headers to Solution Explorer will not automatically let your code discover it. Simply add the directories with headers to VisualGDB Project Properties -> MSBuild -> Include Directories and MSBuild will be able to find them.

You can also use the VisualGDB’s header discovery logic – it should normally locate the missing headers automatically and suggest updating the project properties for you. You can read more about this feature here: https://visualgdb.com/tutorials/intellisense/headers/

[support]

Hi,

Most likely your targets have a different time zone from the development machine. Please consider adjusting them, or simply add the timestamp offset via Tools->VisualGDB->Manage SSH Connections->Per-host Settings. You can also disable the tar timestamps completely in the same window if you want to restore the v5.3 behavior (setting timestamps to the time of transfer, not the original time of the files on Windows).

[Author]

Posts