[support]

Please try creating a new project using the wizard. It should initialize the Python environment correctly.

[support]

Hi,

The easiest way to get it working would be using Quick Debug. Once VisualGDB encounters mismatching file paths, it will show special GUI for locating them on your machine, and will guide you through setting up the path mappings.

You can disable the FLASH loading during Quick Debug by manually removing “load” from the startup commands in the Advanced view of the debug method.

[support]

OK, we have rechecked it. VisualGDB should normally handle it correctly. You can try opening View->Other Windows->VisualGDB Diagnostics, initiating a FLASH programming and checking that the diagnostics console mentions as 1200 bps reset sequence on the correct COM port.

If VisualGDB does mention the reset, but the board does not accept it, the best we can do is share the code snippet on our side that is responsible for resetting the board:

using (var port = new System.IO.Ports.SerialPort(COMPortFromSettings) { BaudRate = 1200 })
{
    port.Open();
    port.RtsEnable = true;
    port.DtrEnable = true;
    port.Handshake = System.IO.Ports.Handshake.RequestToSend;
    Thread.Sleep(1000);
    port.DtrEnable = false;
    port.Close();
}

If you can tweak it to the point where the board can recognize it, we can add a setting on our side to replicate it. Otherwise, you would need to use an oscilloscope/logic analyzer on the COM port pins to figure out the exact difference between the Arduino IDE and our reset implementation. It could boil down to timings on a particular board and a particular COM port, and may just not be worth the effort if it only affects one board.

[support]

This could be tricky. The 1200bps touch indeed isn’t documented very well. VisualGDB does support it for some ESP8266 targets, however the Arduino Uno could be handling it differently.

We are currently fixing a few last-minute issues with the upcoming VisualGDB 6.0R7 and will look into this after that.

[support]

Hi,

No problem. If you only want to override file transfers, it could be easier to disable deployment and source uploads on the VisualGDB level, figure out command-line tools that would do the deployment (ftp client?) and just run custom pre-build or pre-debug commands invoking those tools.

With multiple targets, VisualGDB does support overriding the debug settings, however it only works when letting VisualGDB manage configurations and platforms. If you are using CMake presets, VisualGDB assumes that they can be changed at any moment outside VisualGDB, and tries to minimize dependencies on them. That said, you can try using Debugger Setups. The only difference is that you would need to pick a setup via the VisualGDB toolbar separately from picking the build preset.

[support]

Hi,

No problem, please try this build: VisualGDB-6.0.107.5304.msi. It should fix the issues #1 and #4.

You can override the GDB server command line by switching the debug mode to Custom GDB Stub (VisualGDB Project Properties -> Debug Settings) and specifying the gdbserver command line manually.

The SSH issues are trickier, but not unsolvable. One option would be to use the custom transport interfaces to define your own transport using FTP, Telnet or anything else. VisualGDB will delegate the low-level tasks like running commands to it, so you can ensure it only uses the interfaces supported by your target. Another option would be to patch libssh2 to work with your target, and emulate missing commands like stat. Our fork of libssh2 is published here; you can build a debug version and investigate why it is crashing.

 

[support]

The arduino-builder is a part of the Arduino build system. It is generally good for quick prototyping, but is rather hard to maintain because Arduino packages and libraries keep changing, and you will inevitably end up dealing with some compatibility issues in the long run.

As every Arduino core has its own layout of packages and tools, there is no good universal way of archiving them. You can try making a copy of the entire Arduino15 directory and other package directories, but it will still not work if you end up missing some files. A good long-term solution would be to create a regular STM32 project, and manually port the Arduino-specific code from the Arduino project into it, but it would be quite a time investment.

A somewhat easier way would be to put everything into a VM and make a backup of it.

[support]

Hi,

This is caused by what appears to be a bug in the device definitions on the ST side. Different variations of the STM32G431 device are now defined with different memory layouts, so our BSP generation logic treats them as separate devices.

It will likely get fixed in the next BSP version once ST fixes the device definitions. Until then, you can use one of the 2 workarounds:

1. Manually edit the BSP.XML file, replacing STM32G431RBIx with STM32G431RB.
2. Opening VisualGDB Project Properties and changing the device type from STM32G431RB to STM32G431RBIx

On our side, we have updated the BSP generation logic to keep a track of such changes, and preserve the device entry with the short name, even if the latest SDK appears to split it into multiple devices.

[support]

Hi,

Thanks for checking this. If the Arduino IDE works, but running the same command outside it produces a different result, it could be some system-level setting (antivirus?) or Arduino IDE doing something undocumented (running a different command before it?). Unfortunately, we are not aware of anything specific that could be causing it and don’t have the same board to try it out.

You can try asking on the Arduino forums for any clues to run the programming command line manually (it’s not really specific to VisualGDB). If there is any trick to getting it to program via command line, VisualGDB should be easily able to replicate it, but if it’s something non-trivial deep within the Arduino IDE, there might be no easy way around it.

[support]

Hi,

If it works manually, you can configure it as follows:

1. VisualGDB Project Properties -> Debug Settings -> Debug Using = Full-custom mode
2. Target selection command: target extended-remote blackmagic.local:2345
3. After selecting target: run
4. VisualGDB Project Properties ->Additional GDB Commands -> after selecting a target:
   1. mon swdp_scan
   2. attach 1
   3. run

This should fully replicate the manual setup you described.

[support]

Hi,

Are you using the Arduino build system (Arduino project wizard) or have you manually ported the Arduino libraries to a regular embedded project?

[support]

@raabjo, we are aware that OpenOCD is not perfect. However, it’s an open-source tool that we have little to do with. Specifically, the FLASH programming code in OpenOCD is maintained by ST. We don’t have any special insights into it and do not know why it doesn’t work with a particular binary. You can try using Memory Explorer to compare different binary versions and narrow down some particular trait that can be avoided (e.g. too small sections or unaligned sections), but it may stop working when ST updates the FLASH programming code.

You can also try using Segger J-Link. They have their own fully supported software stack that typically works better than free open-source tools.

[support]

No worries. Their support is usually great and they release updates very frequently, so if you can get them something they can reproduce in their lab, they should be able to fix it.

[support]

It’s too bad those things are like 10x the price of ST-Links….

That’s how much it costs to rigorously test the low-level logic with all the combinations of the devices and modes. The fact that nobody in the several decades managed to offer comparable quality, totally speaks for itself.

As for us, we focus on high-level features: visualizations, analysis, live monitoring, while delegating the low-level to those who excel at it.

[support]

All we did with the FLASH plugin was looked how OpenOCD handles FLASH drivers and made a convenient adapter that lets you create your own FLASH drivers as ELF files, so instead of digging and patching OpenOCD internals, all you need to do is implement a relatively simple interface on he device side. A small improvement to a free open-source tool that makes it a bit more convenient, that’s all.

We have not tested it with every available device. Our fork of the ST fork does include the logic for loading the plugins, but we have not tested it for compatibility with every ST device family.

If you want something more streamlined, you can look into Segger J-Link. They have their own software stack that doesn’t rely on open-source parts like OpenOCD, and usually just works. VisualGDB supports it out-of-the-box, fully interchangeably with OpenOCD. Another option would be to disable memory programming on the VisualGDB side, and run the STM32CubeProgrammer as a custom pre-debug step (see this tutorial).

As for the open-source parts like the FLASH plugin, please consider them reference designs. Like you can go to the ST’s website and get schematics for typical uses of different microcontrollers. But if you make your own board based on one, and it doesn’t work, it’s generally up to you to figure out why.

[Author]

Posts