[support]

Sorry for the late reply. We have discovered a breaking change in ESP-IDF 4.4 that affected unit tests, and had to resolve it. We have updated VisualGDB to support running ESP-IDF unit tests automatically. You can now use the following command line to do so:

VisualGDB.exe /runtests <file.vgdbproj> /targetpath:<full path to the .elf file> /output:<XML file with results>

It should work for all submodules/components that get linked into the same ELF file. You would need to use the following build: VisualGDB-5.6.104.4547.msi

That said, your support period had recently expired. Although this build will work with your key, we advise renewing your key here to get access to further VisualGDB updates and technical support.

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[support]

Thanks for clarifying it. If the solution contains multiple projects, switching it to CMake could have the benefit of separating orthogonal settings:

• Platform-specific settings (e.g. which compiler to use, global optimization flags, etc.) could be stored in a VisualGDB CMake project file
• Target-specific settings (which executables/libraries to build, how do they depend on each other, etc) could be stored in CMakeLists.txt files

You can read more about it here: https://visualgdb.com/tutorials/cmake/multiplatform/

But, if you already have a complex system of MSBuild projects and do not want to change it, using a simple script to convert the settings should be the best approach. You can read more about manually adding VisualGDB platforms in this tutorial. Also, if you need help understanding specific settings, feel free to let us know.

[support]

Hi,

The logic for adding configurations is indeed intended for the regular Win32 projects, so that you could have Win32 configurations in parallel with VisualGDB configurations. The regular VS Linux projects use a different layout and the configuration adding logic won’t work for them.

The easiest way to import an existing project into VisualGDB would be to use the import mode of the wizard. It will automatically add all sources and headers from the specified directory to the new project, although you would need to specify other settings (e.g. preprocessor macros) manually.

You can also try using CMake to build your project. VisualGDB integration with CMake is far more advanced compared to the regular VS one (e.g. see our CMake script debugger) and at the same time will give you an easy option to build the project outside VisualGDB if you ever need to do so.

[support]

Hi,

This is correct. Qt-specific items can be added via the “Add Existing Item” command, or by editing CMakeLists.txt file manually.

[support]

Hi,

The mechanism for retesting the toolchain with every setting change is only used in the legacy GNU Make-based project type. Newer MSBuild-based and CMake-based projects do not need it and should generally work better (also building the project after changing settings will be faster). If this is not an option and you need to use GNU Make, you can simply ignore the “toolchain testing failed” error.

[support]

Hi,

The standard C library provides a few functions faster than printf(). They all work via the same backend provided by the fast semihosting. You can get a good overview by setting a breakpoint at WriteToFastSemihostingChannel(), calling printf(), checking the call stack involved in the call, and manually calling some of the lower-level functions shown in that call stack. Using puts() could be another option.

Regarding STM32CubeMX, its output usually varies a lot between different versions (and is often buggy), so we try to steer clear of adjusting anything automatically to avoid breaking it even further. Patching it manually could be a reasonable workaround (just make sure you check in the generated files into source control). Another option would be to use the “Exclude from build” command in Solution Explorer to ignore the entire file.

[support]

Hi,

The SRAM option works the same for all devices – places all code and data into SRAM. This allows testing out the code without programming the FLASH memory, that could be faster in some times.

If you wish to copy the code from FLASH to RAM, you would need to handle it manually. VisualGDB does not have any special GUI setting for it. If you need a quick example or an explanation how to do it, feel free to reach out to our sales email for a quote.

The OpenOCD support for new devices is usually introduced a few months after a device has been released. ST shares it with the OpenOCD developers, they push it into the master branch, and our build system picks it up. Until then, there are a few options to use the device:

• Select “do not program FLASH” in VisualGDB Debug Settings and use the STM32CubeProgrammer as a custom pre-debug step
• Use Segger J-Link that usually supports new devices earlier
• Try selecting the ST fork of OpenOCD in the VisualGDB Debug Settings
• If the patches for the new device are in review, you can manually apply them to OpenOCD and rebuild it

[support]

No problem. If you ever get more weird behavior with ITM, feel free to try the live watch with counter test – it should reveal memory reading problems fairly fast.

Also, feel free to check out the Test Resource Manager. It may prove useful for complex setups (e.g. you can write multiple binary log files and analyze them programmatically later).

[support]

Hi,

It looks like your VisualGDB installation is corrupt (missing MSBuild platform), or you have edited the project in a way that breaks MSBuild integration. In order to resolve it, please try:

1. Uninstalling VisualGDB completely and deleting its directory
2. Installing it again
3. Following the tutorial to the letter to create a new project from scratch.

If it still doesn’t work, 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.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Hi Timo,

Thanks for narrowing it down. Indeed, we have never tested out the ITM simultaneously with the semihosting. The two interfaces rely on completely different mechanisms, so they should normally not interfere with each other. However, there could be secondary factors interfering with the memory reads.

The most likely model of what is going on is below:

1. The profiler framework sets WriteOffset to a correct value
2. The profiler framework proceeds to output a character via ITM
3. Simultaneously with #2, VisualGDB tries to read WriteOffset and gets a larger value than it actually is
4. VisualGDB updates ReadOffset to match the unexpectedly high value
5. VisualGDB reads WriteOffset again, that is now permanently lower than ReadOffset and interprets it as a “no new data” condition.

We are somewhat reluctant to trying to reproduce it on our side, because such issues are often caused by environment-specific factors (e.g. SWD crosstalk, power, timing of a specific chip, or bug in a specific hardware revision of J-Link). If it doesn’t affect your regular workflow, we would advise just ignoring it. Alternatively, we can share the instructions to log the interaction between the profiler framework and VisualGDB, that will allow narrowing down the specific incorrect value, but it won’t explain what is causing it.

Another quicker test would be to run a program that increases a global counter and calls ITM_SendChar() in a loop. Then, you can try plotting it with Live Watch and look for irregularities. If some interference between ITM and memory reads exists, it should eventually show up here as well.

The cursor behavior is a known bug caused by the interaction between WPF, WinForms, and the Win32 caret API (VisualGDB ends up rendering the cursor on top of the wrong window due to the timing of the window activation events). It sometimes occurs when having multiple console windows visible at the same time, and usually settles when you start interacting with one of the windows. Other than for the cosmetic effect, it is completely harmless and won’t cause any data loss.

[support]

Hi,

No problem, please find the answers below:

1. The buffer is emptied and read out by VisualGDB via the background memory reading commands (e.g. mdw in OpenOCD).
2. Fast round time should not be a problem. The framework can automatically pause and wait for VisualGDB to read out the data.
3. The “discard further data” setting is useful if the target is producing the data faster than the JTAG debugger can read it.

In general, the issue you are describing looks like a memory corruption somewhere in the project. Under normal circumstances, ReadOffset should always be less or equal to WriteOffset. If this is not the case, something else in the code likely sets one of these fields to an incorrect value, preventing further semihosting operation.

[support]

Yes, exactly.

[support]

Thanks for clarifying this. In this case, your toolchain likely contains a very old make executable that does not support some commands. Please consider replacing it with a make.exe from the VisualGDB directory. It should not affect the rest of the toolchain (e.g. the compiler) and should fix the problems with the Makefiles.

[support]

Hi,

The fast semihosting pays off when using larger payloads (e.g. outputting large logs to the resource manager). It will also be somewhat faster if you switch to the release build, as the optimizer will eliminate a lot of unnecessary instructions.

The extra delay compared to ITM comes from the logic used for combining multiple output streams (profiler, live coverage, test resources, printf) and is optimized for real-world scenarios (moderate to heavy data flow). We never optimized it for synthetic tests on smaller payloads, so it may indeed be slower than ITM (although still much faster than one can read).

[Author]

Posts