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.

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.

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

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.