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

[support]

We have a very detailed page describing the scope of our support here. It is linked directly from the buy page.

As for learning, embedded development can be harder than other areas. Often a subtle change to some configuration parameter or device register causes weird behavior, that takes hours or even days to troubleshoot. There is no automatic way of fixing such issues, it requires careful thinking, experimenting, and becomes easier as you gain experience.

If you would like to use VisualGDB to learn embedded development, we would advise starting with easier examples, getting a good understanding how they work, and carefully trying to change one thing at a time, to learn from it. That way, if you end up breaking something, you can always step back and forth until you find the root cause.

Unfortunately, it is not realistic to just copy-paste some code or error messages into the support form and expect the support of a debugging/productivity tool to fix or explain it.

Either way, if you have just purchased our product, feel free to contact our support and we will be able to cancel your license and refund your order.

[support]

Sorry, we do not have any other instructions. If you are not able to follow them, please consider reading more about the involved tools, or doing something easier.

[support]

Hi,

This is most likely caused by some subtle differences between the OpenOCD scripts used by STM32CubeIDE and VisualGDB. You can troubleshoot it as follows:

1. Try starting OpenOCD manually using the command line shown in the VisualGDB Output window. Make sure it listens at the gdb port specified via command line (see the log for more details).
2. Try starting arm-eabi-gdb.exe <your ELF file> and run the following commands:
   • target remote :<gdb port>
   • load
   • break main
   • run

If you can reproduce the same problem (connection gets lost instead of being able to hit breakpoints and step), you would need to try switching out parts of the setup with STM32CubeIDE equivalents:

1. Try running OpenOCD from STM32CubeIDE with its script
2. Try running VisualGDB’s OpenoCD with the script from STM32CubeIDE
3. Optionally, try comparing the scripts and moving individual statements between them

If you can find a particular statement in the script that triggers the problem, feel free to let us know and we might be able to add a GUI option for controlling it directly.

[support]

Hi,

Sorry, due to several complications in the way VS handles debugger interfaces, VisualGDB only supports debugging one application at the same time.

If you would like to debug 2 applications simultaneously, you would need to run 2 separate Visual Studio instances having 2 different solutions.

That said, two solutions can easily reference the same static library (embedded targets do not support shared, i.e. dynamically loaded libraries anyway).

[support]

Hi,

Sorry, this doesn’t look like any known issue. If you can reproduce it on a clean project created from scratch, and share the exact repro steps, we should be able to fix it, or suggest a workaround.

[support]

Hi,

This can be related to the setting updating mechanism. You can try opening the VisualGDB Project Properties window and checking the Apply button. When you initially open the window, the button will be grayed out, but when you change the first setting, it will become enabled.

You can try that with the IP address setting. If changing just that setting does not affect the Apply button, it could be a bug on our side. If this is the case, please attach the screenshot of your properties window specifically showing the setting you changed, and we will look into it.

[support]

Hi,

It looks like something between OpenOCD and your board. You can try asking ST, or tying the OpenOCD version/scripts from STM32CubeIDE.

If you can get OpenOCD working outside VisualGDB, we can help you configure VisualGDB to replicate the same result.

[support]

Thanks for renewing your support. Based on the last screenshots you provided, you have left the “target selection command” in VisualGDB Project Properties -> Debug Settings empty, so it confuses VisualGDB’s logic for detecting whether the target is running.

The target selection command should be “target extended-remote blackmagic.local:2345“. Commands like “set mem …” should go to “Additional GDB Commands -> commands before selecting a target” and commands like “mon swp_scan”, “load”, etc should go to “commands after selecting a target”.

[support]

Hi,

This error means that the plugin for decoding the RTOS thread state is corrupt. Please try completely uninstalling VisualGDB, deleting the Program Files (x86)\VisualGDB directory, and installing it back.

If it doesn’t help, you can try disabling the RTOS-specific functionality via VisualGDB Project Properties -> Embedded Debug Tweaking -> Embedded RTOS Support = Disabled.

[support]

Hi,

It is mostly up to the device vendors. Once ST and others begin shipping Rust examples and Rust templates, we will add support very promptly. Until then there will simply be not enough users, sorry.

[support]

Hi,

That would be VisualGDB Project Properties -> Custom Build Steps -> Before transferring files.

That is assuming that by “scanning for out of date files” you meant VisualGDB scanning for files that should be re-uploaded to the target.

If you meant something else, please let us know more details. E,g, if you are talking about the Visual Studio’s logic for determining that a project is up-to-date and skipping the build entirely, you can try disabling the fast up-to-date check via the first page of VS  project properties (not VisualGDB project properties).

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

The VisualGDB’s logic for transferring files to the target is completely separate from the contents of the .vcxproj files. So, you can set it up like this:

1. Run the custom Makefile as a custom pre-sync step (not pre-build step). It will run before VisualGDB computes which files need to be uploaded to the build machine.
2. Ensure the file synchronization settings reference all relevant directories. They don’t have to be inside the project directory. You can configure VisualGDB to arbitrarily upload everything in $(ProjectDir)\..\shared to $(BuildDir)/../shared, and it will handle it just fine, even if some files in shared were just updated by the custom pre-sync step.

You can also have a mix of custom Make invocations and custom file upload jobs in the pre-build steps or as manually invokable custom shortcuts, if you want to make the entire setup more modular, and reduce the amount of files checked/updated at once.

[Author]

Posts