[support]

Hi,

Thanks for pointing this out! We will look into updating the Clang version used by VisualGDB, so that it handles the gnu2b natively. Until then, gnu17, or gnu2x should work.

[support]

Hi,

Last time we checked, it could be safely ignored. If you install the same packages with Arduino IDE, it just silently skipped these long paths, and everything still got built just fine. So, we just replicated its behavior, but added a warning just in case.

We would advise against registry hacks, as it could have some weird side effects (e.g. cause some internal errors in gcc). You can also try convincing Espressif to update their package structure, as it might eventually start causing problems for Windows users.

[support]

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,

We are still working on official integration (should be ready in a couple of weeks). If you don’t want to wait, you can try copying the VisualGDB’s folder from VS2022’s Extensions folder to the VS2026 Extensions folder, and enabling VisualGDB in the VS Extensions menu, but it may not work (we haven’t tested it).

Once we officially support it, it will work out-of-the-box.

[support]

Hi,

Thanks for renewing your support.

This behavior is somewhat expected with the GNU Make projects. The regular Make project subsystem expects a particular Makefile layout, that places a few constraints on the project structure. One is that the build command should always run from the Makefile’s directory. The other one is that CFLAGS and other settings should be specified in a very rigid way, so VisualGDB can edit them using relatively simple regular expressions. You get the general idea by creating a new Make project, changing a few things via the GUI, and checking what files got changed as a result.

If you have an existing big project with non-trivial Makefiles, we would advise importing it as an externally built project. It will remove all constraints on the command line, but things like include directories would require manually updating the Makefiles.

A better (but more time-consuming option) would be upgrading to CMake. Unlike Make, CMake can produce machine-readable information about the project structure, so unless you do something really tricky (like custom macros), you can just select a target in Solution Explorer, change its properties, and VisualGDB will automatically find and edit the correct CMakeLists file defining that target.

[support]

OK, good news for all ESP32 users. We have looked into the tool structure used by the Espressif’s VS Code extension, and they look very solid and well-organized.

So, we updated VisualGDB to directly use exactly the same packages that the VS Code extension does, and hence produce exactly the same results. You no longer need to wait for an updated toolchain from us; any IDF/ADF version from Espressif that works with VS Code now also works with VisualGDB out-of-the-box, producing exactly the same results.

You would need to update to the latest VisualGDB 6.1 Beta 1 in order to use the new setup.

We also published a detailed documentation page on the new project structure here: https://visualgdb.com/documentation/espidf/consolidated/

[support]

We don’t know what is really done in ST-Link or J-Link debug tool either. All we can do is show you how to configure VisualGDB to automatically run STM32CubeProgrammer CLI before debugging.

[support]

Hi,

You can always post on the forum, and if anyone else decides help, they are always welcome to do so. We just post a standard reply with the renewal link, so others would know why we are not investigating it further.

Either way, yes, the support and upgrades are always combined. You can generally use any VisualGDB version that was released before the support on your license expired. So renewing the license would always allow installing any version released before the renewed support period expires.

[support]

Hi,

Thanks for pointing this out. We have fixed it in the following build: VisualGDB-6.1.0.5377.msi

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

This looks like a log file, not a command line. Please make sure you can launch STM32CubeProgrammer to do it via command line (not GUI).

[support]

Hi,

You would need to figure out the exact command lines. You can try asking the ST support, or using tools like procmon to record the command lines. There is no other way to configure VisualGDB, unless you can find out these command lines.

[support]

Hi,

VisualGDB does not interact with the debugged devices directly, and instead uses various vendor-supplied tools like OpenOCD.

If STM32CubeIDE does it automatically, it likely has some special OpenOCD command in the script, or a command-line tool that it runs before or after debugging. You would need to find that out and make sure you can get it working with command-line tools alone.

Based on your findings, we can then help you configure VisualGDB to launch these tools automatically.  If it’s a stand-alone tool, you can add it to VisualGDB Project Properties -> Debug Customization -> Pre/Debug steps. If it’s an OpenOCD script command, you can configure it via advanced settings on the Debug Settings page.

[support]

This looks like the loading now happens after target external-remote, but before the attach command. You can probably work around it by creating a do_attach.gdb file, that would add a hook and immediately issue the “attach” command, and then replacing “attach” with “source …/attach.gdb” in VisualGDB Project Properties (and removing the old hook.gdb reference).

That said, it could be way easier to use one of the proper hardware probes supported by OpenOCD. The problems you are encountering happen because the Black Magic Probe developers decided to reimplement some of the OpenOCD functionality, and ended up reimplementing it differently enough to cause various glitches. It should be possible to work around them, but if you don’t want to dive into the GDB internals, it may simply be not worth it.

[support]

Hi,

Sorry for the delay. Based on what we can see, the Black Magic Probe reports the gdb events in a rather unconventional order:

attach 1
*running,thread-id=”1″
^done
*stopped,frame={addr=”0x08001fdc”,func=”SetFilterAdc”,args=[{name=”pu16_AdcDataTab”,value=”0x200009ac <au16_AdcReadTab+8>”}],file=”E:\\MesDocuments\\Code_source\\BlackMagicProbe\\Sensor\\Sensor_App\\Core\\Src\\adc.c”,fullname=”E:\\MesDocuments\\Code_source\\BlackMagicProbe\\Sensor\\Sensor_App\\Core\\Src\\adc.c”,line=”558″,arch=”armv6s-m”},thread-id=”1″,stopped-threads=”all”

So, when VisualGDB asks it to attach to the target, it reports that the target is running (and hence won’t accept commands like “load”) and then after some time that changes to stopped.

You can try checking the black magic probe documentation whether there is a flag overriding this behavior.

If not, you can try experimenting with gdb hooks. E.g. create a file called hook.gdb in the project directory:

define hook-stop
  if !$hooked_load
    load
    set $hooked_load = 1
  end
end

Then, using VisualGDB Project Properties, add “source $(ProjectDir)/hook.gdb” as a pre-target command. This will force GDB to set the hook on the first stop that would run the “load” command.

[Author]

Posts