[support]

Every Linux target needs its own cross-toolchain specially built for it. There is no universal toolchain that will work for all targets. We can give you a quote for building a toolchain for you, or you can check with the target vendor if there is a ready-to-use toolchain.

[support]

Hi,

The riscv64-unknown-elf-cpp toolchain is meant for barebone targets (i.e. without OS) and may not work with Linux systems. You can force VisualGDB to use it by deleting the toolchain.xml file and re-importing it manually by pointing at the gdb executable, but it will likely not work correctly with the Linux target.

[support]

Hi,

There is no direct mapping of registry keys into VisualGDB parameters, however you can use custom per-user variables (see this page) or define it via a system-level environment variable, and just reference it using the regular variable syntax.

[support]

Hi,

Good to know it’s starting to work.

Running GDB locally would be happening if you did not enable the “Allow choosing build/clean/debug command hosts independently” checkbox in VisualGDB Project Properties -> Linux Project. If it is set, you would need to double-check the host configured in the GDB command selector.

VisualGDB passes -v to killall so that it could log errors reported by it. We’ll monitor feedback from other users and will consider adding an option to disable it if it causes trouble on other systems. As a workaround, running killall as a custom pre-debug step should work just fine.

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

[Author]

Posts