[support]

Hi,

uVision 5 shows every possible FLASH memory because it comes with pre-built FLASH programming plugins for those memories. VisualGDB uses a different approach – instead of providing ready plugins for all common FLASH memories (that would considerably raise the VisualGDB license price due to the overhead of maintaining them), it offers a FLASH driver plugin interface that lets you create a plugin for the device you want to use. We also offer paid service of creating FLASH plugins on demand (please contact our sales if you would like to get a quote).

We are aware of the text scaling issues. The “Additional Memories” page is one of the last property pages that was not switched to the newer WPF technology (that is 100% compatible with high-DPI displays) and hence may appear distorted. We should be able to fix it in the next major VisualGDB release.

[support]

Thanks for sharing this!

[support]

Hi,

Do you mean the path where VisualGDB deploys the executable? If yes, please use the “deployment path” setting on the Debug Settings page of VisualGDB Project Properties.

[support]

Hi,

Please follow the instructions from Espressif on configuring the toolchain for ULP projects.

[support]

Hi,

The red cross in front of the header file means that it does not participate in build. This is expected for header files – they are never compiled directly and are always analyzed in the context of a source file (.cpp) including it. Please try reproducing the original problem with the missing headers when including them from a source file, not another header file. If it can only be reproduced when including files from headers, please ensure that the header file triggering the problem is actually included from one of the sources (otherwise VisualGDB will try to guess the compiler flags for it based on the most commonly used flags and it may not be accurate for multi-target CMake projects).

The CodeModel.json file should be located in the following path:

<Directory of the main CMakeLists.txt file>\<Binary Directory from VisualGDB Project Properties>

If your project was imported from a different directory, please search the subdirectories of that directory for the CodeModel.json file instead of the directory of the VisualGDB project itself.

The double header problem could be caused by enabling the automatic header location inside the target directories. Please double-check the “VisualGDB Project Properties -> CMake Project Setings -> Automatically find header files” setting. It needs to be set to “Disabled” if your headers are explicitly specified via CMakeLists.txt files.

[support]

Hi,

Thanks for the detailed description. Just FYI: the latest version of the GoogleTest package is 20190124-1.8.1, not 20181002-1.8.1. It might resolve some of the issues.

Please also check that the TFS machine has the latest VisualGDB version installed (you might have deployed an earlier version of VisualGDB there manually and have not updated it). You can check the build number via File Properties on the VisualGDB.exe file.

If updating doesn’t help, please confirm whether you are getting the coverage files when running VisualGDB.exe /runtests from your main machine (not from the TFS machine). If not, please try adding “/v” to the VisualGDB’s command line and share the updated output. Please also check if the coverage files are created on the deployment machine in the directory specified via VS Project Properties -> Instrumentation -> Coverage Report Directory. If not, please double-check that the directory is writable.

VisualGDB indeed uses the gcov from its own directory, however it should not cause any problems as the processing it performs is platform-independent.

[support]

Hi,

Sorry about that. It was indeed a bug on our side triggered by a switch to the MinGW2-based environment. We have fixed it and released an updated R17 toolchain.

[support]

Good to know it works. If you would like to find out why the I2C frequency setting affects debugging, please consider creating a thread on the ST forum – someone from the ST community might have an insight into this.

[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.

[Author]

Posts