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

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

Hi,

It looks like your toolchain is not compatible with your target. Please make sure you use a compatible toolchain.

If you are not sure which toolchain you are using anymore, please follow the instructions on this page to reset everything. If it still doesn’t work, please share the repro steps including the screenshots (also showing how you write the SD card image) and we will point out the cause of the issue.

If you are completely unfamiliar with the Linux toolchains and cross-compilation, and do not want to research it on your side, we can gladly walk you through everything at our consulting rate. Please contact our sales if you would like to get a quote.

[support]

Hi,

It generally depends on the project type you are using. For MSBuild/Make you could use the regular Visual Studio’s configuration manager. For a multi-target Advanced CMake project, the configuration would be the same for all targets, so you would need to manually override the CFLAGS for a particular library.

[support]

Hi,

Sure, you can use VisualGDB Project Properties -> Custom Build Steps to run an arbitrary command after the entire build finishes.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please 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. See this page for more information and detailed examples.
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.

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,

This is by design. VisualGDB can automatically do things that are, well, automatable. ESP-IDF comes with various examples that can be built using the same CMake interface, so VisualGDB can automatically clone and build them for you. ESP-IDF uses KConfig to edit various configuration parameters, so VisualGDB offers a neat searchable GUI for working with them.

To our best knowledge, ESP-IDF does not come with a machine-readable description that would cover the functionality you described, hence VisualGDB cannot automatically do it.

[support]

Sorry, your trial expired a while ago. If you would like to get any further technical support, we would kindly ask you to purchase a license.

[support]

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

[support]

Hi,

VisualGDB takes the list of ESP32 devices from the <SysGCC>\esp32\esp32-bsp\BSP.xml file, so you can try editing it, although it may take a few attempts to get working correctly.

That said, ESP32C6 looks interesting, so we will try to get one within the next month, and will consider adding out-of-the-box support for it, if the new ESP-IDF branch works out-of-the-box.

The ESP32 debug methods package you mentioned was from last year (the latest update was still being tested). We have just released another one (20230309) based on the latest OpenOCD release from Espressif. Feel free to check the Espressif’s release logs for the exact list of changes.

[support]

The Arduino-based projects are different from the regular ESP-IDF projects. They rely on the Arduino framework (using the rules in the ESP32 Arduino core) to build and program the project. Programming FLASH for Arduino projects is done via the COM port (same when using the Arduino IDE).

If the regular ESP-IDF projects work, you can use VisualGDB to develop them via the ESP-IDF project wizard (not the Arduino project wizard).

If you are getting different behavior between the regular ESP-IDF projects and Arduino projects, it is likely caused by differences between the ESP-IDF framework and the Arduino framework (that internally uses a different version of ESP-IDF and a completely different set of rules to build the code). Using VisualGDB on top of either ESP-IDF or Arduino will not change the way the underlying framework operates and will not eliminate the differences between these 2 frameworks.

[Author]

Posts