Hi,

Please try switching the debug method to full-custom mode. Then specify the following:

Then create a file called connect.gdb in your project directory and paste the attaching commands there:

target extended-remote COM3
attach 1

Then finally go to the Additional GDB Commands page and add the following post-target command:

load

Could you confirm that running the same gdb commands manually (in a gdb instance started from command line) works? If yes, please share the full gdb log (can be enabled on the Advanced GDB Settings page of VisualGDB Project Properties) and we will investigate.

Hi,

Thanks for sharing this.

The Live Variables rely on the debug probe’s ability to provide an independent interface (completely parallel to GDB) for accessing the memory. Last time we checked, BMP did provide such an interface.

If anyone could patch the BMP sources to support a separate memory access interface, we will be happy to share instructions on creating a VisualGDB debug plugin to use it similarly to OpenOCD and J-Link.

Just a separate UART port won’t be sufficient for live variables. Some logic on the BMP side would need to handle the “read memory at address XXX” commands via this port, do the actual reading via JTAG/SWD and return the result.

Alternatively, we can add an API similar to the custom real-time watch that will let your program report arbitrary values via a connection such as a COM port, so VisualGDB will plot them.

Yes, we will try to add something similar in one of the next major releases.

We would advise first getting it working with an instance of gdb manually launched via command line. Once you can confirm that it works reliably, feel free to let us know the tools and commands lines involved, and we will help you configure VisualGDB to replicate that setup.