[support]

Hi,

The ARM64 compatibility should not affect firmware downloading. The regular F5 command may not work for some project types, but the Debug->Start debugging with GDB should work.

Can you confirm that the project build speed is reasonable and that running J-Link GDB server with the command-line gdb works as expected? If the underlying tools do not work on ARM64, resolving the VisualGDB issues won’t automatically fix it.

[support]

Hi,

OK, we have published a detailed reference covering the live watch plugin API here: https://visualgdb.com/reference/extensibility/html/N_VisualGDBExtensibility_LiveWatch.htm

We also published 2 tutorials that should help anyone interested get started with Live Watch plugins:

• Creating a basic Live Watch plugin
• Creating custom Live Watch nodes

We will publish another tutorial on discovering multiple objects and iterating lists next week.

The tutorials assume no prior C# knowledge, so they explain all key concepts, show how to use Visual Studio to setup the projects, add classes, etc. They also cover the non-trivial C# syntax that is different from C++.

If you have any feedback regarding the new documentation, feel free to post it here.

 

[support]

Hi,

The first code snippet you posted should work just fine. You can retest it by creating a simple STM32 project and copying it there.

If it’s not working in a more complicated McuXpresso project, the issue is likely caused by some hard-to-see difference (e.g. a space in some identifier that breaks CMake argument order). The easiest way to narrow it down would be to use the CMake debugger to step through a working STM32 setup and a broken McuXpresso setup side-by-side, until the difference becomes obvious.

[support]

Thanks for sharing this. BTW, we have published a tutorial showing how to use the ST-Link GDB server with VisualGDB here. We will watch for feedback on it and will consider creating an out-of-the-box debug package for it, similar to the OpenOCD one.

[support]

Hi,

Please let us know the email address associated with your license key, so that we could check your support status.

[support]

Hi,

Thanks for renewing your license. We have investigated and fixed the issue. Please try this build: VisualGDB-5.6.109.4849.msi

[support]

Hi,

We have not tested it on our side, however you can easily try it out by creating an MSBuild-based project and switching from the Clang IntelliSense to the regular VC++ IntelliSense.

Such project will look like a regular VC++ project from the Visual Studio side, so any extensions that work with the regular VC++ projects will work with it as well.

[support]

Hi,

You can configure VisualGDB to reuse the existing build scripts, however you should be first able to build the same project using the same build file via command line on the same machine you are intending to use with VisualGDB.

If you can get it working, please share the command line that worked for you, and we will help you configure VisualGDB to use it as well.

If you are not familiar with the Linux build systems and would like us to explain to you how they work, we can gladly do it at our consulting rate, however it is not included in our product support.

[support]

Hi,

Sorry, adding a scripting engine in another language (and making sure the scripts are debuggable) would be orders of magnitude more complex than reusing the .Net framework that is already used for Visual Studio extensions, and VisualGDB itself. It would also very likely cause compatibility problems with other extensions, or some Visual Studio versions, due to the sheer complexity of this solution.

If you are not familiar with C#, we can gladly add a few tutorials showing some basic use cases, so you could tweak the logic shown there without having to go in-depth into the C# semantics. Let us know if you have any use cases in mind.

[support]

Hi,

Good to know it works. Let us know if you encounter further issues.

[support]

Hi,

The “Signal 0” error means that OpenOCD has lost connection to the target. It typically happens when the target program disables some functionality needed by JTAG/SWD (e.g. remaps the SWD pins to GPIO). The best way to troubleshoot it is as follows:

1. Set a breakpoint very early in main() or use F10 instead of F5 to start debugging. Make sure it works.
2. Set a breakpoint in some other code that is supposed to run slightly later and press F5 to continue
3. If the second breakpoint worked, set another one even later. If not, restart the program and set a breakpoint between the ones in steps 1 and 2.

If you see that a breakpoint at the beginning of a long function works, and another one at the end doesn’t, you can step that function with F10 until the debugging stops working.

This should help quickly locate the code responsible for breaking the debugging, and comment it out (or check if it’s #ifdef-ed against some macro that you can define).

[support]

Hi All,

@murrellr, sorry for the delay. We are still working on a comprehensive reference of the live watch API, similar to the expression visualizers API reference. We expect it to be finished in 1-2 weeks from now, and will also publish a detailed documentation page explaining the key concepts.

As for the wizard, writing code (and creating plugins) is only needed for complex scenarios (e.g. scanning heap, detecting object types, displaying them as lists).

For simple use cases, you can just use the “globals” view under the Live Watch. It automatically locates all variables in the ELF file, and lets you quickly locate/view the ones you need. If you would like to just view a group of key variables, you can simply tag them as favorite, and then use the favorite-only view. If it helps, we can add a mode for virtual views, where you would create group nodes and drag some variables underneath them.

@bflannery, could you please elaborate more on what you meant? The live variables in the global view are automatically inferred from the ELF symbols (and there is even an option to show their values right in the code editor). If you meant something different, it would be great if you could provide an example.

[support]

Hi,

Pico SDK projects are based on the Advanced CMake project subsystem, so they follow the settings layout of the CMake projects. You can specify the language standard on the target level by selecting a target (node with the console icon) in Solution Explorer, going to its properties, and changing C/C++ -> Advanced -> Language Standard for C++ files.

[support]

Hi,

No problem, please see the answers to your questions below:

1. We have just rechecked the latest OpenOCD release from ST, and it looks like our build already has all the latest commits. The version number reported by the binary could be different due to the differences in build scripts, but otherwise it should be identical. However, the OpenOCD script files used to configure it could be different: STM32CubeIDE generates them dynamically based on some internal logic, and might insert some additional statements to handle QSPI. We would advice approaching it as follows:
   1. Make sure you can program and debug everything via command-line gdb + OpenOCD from STM32CubeIDE
   2. Make sure you can reproduce the problem with command-line gdb + OpenOCD from VisualGDB
   3. Try using setup (a) with binary from (b). It should normally still work as the binaries are identical.
   4. Inspect the OpenOCD scripts used by (a) and (b) looking for FLASH-related commands (flash <…>). Try copying them from the script file used in (a) to a copy of the script file used in (b).
   5. Once you get the modified script file working, you can configure VisualGDB to use it via VisualGDB Project Properties -> Debug Settings -> Advanced -> Command Line. You can use variables like $(ProjectDir) to avoid hardcoding paths there.
2. If you would like to program the memory separately, you can add a command line for doing so to VisualGDB Project Properties -> Custom Debug Steps (to do it automatically), or Custom Shortcuts (to do it manually via a context menu command). Then, disable the regular memory programming via the Debug Settings page.
3. VisualGDB always produces the ELF file and never deletes it. It normally has the same name as the .bin file, and no extension.
4. If you have imported a STM32CubeIDE project, and are changing it, VisualGDB would check for changes when you open the VisualGDB project. You can force it to recheck it by closing and reopening a solution, or by reloading the project via context menu in Solution Explorer (not for all project types). Another option would be to use the advanced STM32CubeMX workflow – it internally uses the same importing logic, but nicely separates the STM32CubeMX-generated part from anything you would add later in Solution Explorer, and also has a context menu command to launch STM32CubeMX, and apply any changes it makes.
5. If you absolutely want to use a custom OpenOCD executable, you can select “Custom GDB stub” in VisualGDB Project Properties -> Debug settings and specify the command line manually, however you will lose some advanced features like automatic substitution of USB serial numbers (for multiple ST-Link probes) and live memory reading. Using the regular OpenOCD method with a custom script should work much better.
6. The STM32H747XI linker script you mentioned looks different from the default one. Please double-check where did it come from. If it’s located in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\2020.10\STM32H7xxxx\LinkerScripts, it was generated by us and could indicate a bug in our BSP generator. If it comes from %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\2020.10\VendorSamples, it was copied “as is” from the ST SDK, and could indicate a bug in the ST SDK that will likely be fixed in the next SDK version. In the latter case, please consider simply patching the file on your side as a temporary fix until ST fixes it properly and we release an updated BSP with the latest patches.

[support]

Hi All,

@bflannery, thanks for your suggestion, but the tutorial you pointed out is meant for a much more complex case – trying to program external memories (e.g. SPI FLASH) that are not supported out-of-the-box. The regular on-chip FLASH memory and the memories that have drivers from ST should not need it.

@AndyCap, indeed, the OpenOCD version shipped with STM32CubeIDE comes from a different repository. ST typically adds support for new devices there, and in a few months it gets ported (with some changes) to mainline OpenOCD. Either way, please try selecting OpenOCD (ST fork) instead of the regular OpenOCD in VisualGDB Project Properties -> Debug Settings. It is based on the ST fork and should work the same way as STM32CubeIDE. If it still doesn’t work, please let us know, and we will update it based on the latest release tag from ST.

We can also help you configure programming and debugging separately if you wish, but using the ST fork of OpenOCD should be much easier.

[Author]

Posts