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

[support]

Hi,

Indeed, the setting has moved to the Embedded Debug Tweaking page.

[support]

No problem, we have updated the step 6 of the tutorial.

We absolutely did not mind your post. You provided a very accurate description of the issue, and sufficient information for us to fix issues within our control, making VisualGDB better for every other user interested in ITM.

For context, at the time the tutorial was made, there was not much documentation on the “SWO EnableTarget 0 0 1 0” command on the Segger side, so we suggested using it as is. Over time, a couple of users reported issues with ITM, so we redirected them to Segger support (since the ITM handling is implemented inside the J-Link software) that helped them resolve the issue. Turns out, Segger updated the documentation on their side, and was likely directing the users to it. Now that we have updated the tutorial to point to the new documentation, it should make things easier for everyone.

[support]

Hi,

This looks like an issue of a specific demo project, and not a VisualGDB bug. Please note that if the project doesn’t build from command line, importing it into VisualGDB will not automatically fix the build errors, since VisualGDB would be using exactly the same command line producing the same result.

[support]

Thanks for narrowing it down. Indeed, the directory would usually be created by other MSBuild targets, so InitializeBuiltProjectContext did not need to do it. It is hard to say why this project is different, but we have simply added an extra check for creating the directory if it was missing. Please feel free to try this build: VisualGDB-5.6.104.4545.msi

[support]

Hi,

Thanks very much for the very detailed description. Indeed, the Wiki page you linked is newer than the one we used when writing the tutorial and explains the SWO EnableTarget command much better. We have added a new step to the tutorial (#13) explaining how to specify the frequency manually and linking it to the new Wiki page. We have also added a note about the VisualGDB Output window used in the newer VisualGDB versions.

[support]

Hi,

This looks like a rather complex setup that contains some rare combination of settings triggering unexpected behavior. The best way of troubleshooting it would be to reproduce it on a clean project from scratch and document the exact steps it takes to trigger the issue. Most likely, the issue will start happening after you change some specific setting.

If you can describe the setting that triggers the issue (or the entire repro steps with the relevant screenshots), we should be able to suggest a fix/workaround.

[support]

Hi,

The ESP32 semihosting (apptrace) is implemented by the Espressif’s OpenOCD fork. Last time we checked, it only supported device-to-host transfers (i.e. saving the output generated by the device to a text file via the esp32 apptrace start command).

Feel free to double-check this with Espressif – if there is a reliable way to send the data to the device via the same mechanism, we can gladly add support to it on the VisualGDB side.

[support]

Sure, you can always download the packages manually via this page and install them via the VisualGDB Package Manager.

If you want to see all package versions, you can always use the following link to download the package catalog file manually: https://visualgdb.com/hwsupport/catalog?version=latest

 

[Author]

Posts