[support]

Hi,

No problem, please see below for the list of suggestions:

• You have configured VisualGDB to synchronize the directory of every project using MRS-RDP-LINUX to the same remote directory defined via environment $(ProjectDirLinux). It means that whenever you open ANY project using the Linux machine, the contents of its directory will be copied to $(ProjectDirLinux). If you have the .vcxproj/.vgdbsettings files in many different directories, it will copy them ALL into the same $(ProjectDirLinux) directory. You probably didn’t intend to do that – if you just want to create a path translation rule, the setting on the Project Settings page is sufficient. Synchronized Directories page configures VisualGDB to physically copy files to certain locations. If you are copying the files manually, you do not need this setting.
• The error message on the screenshot mentions the ../src/bit/bit.cpp file. It is located outside the project directory, so whatever path mapping you set for $(ProjectDir) wont cover it, because the path is not inside $(ProjectDir).

Please consider setting up a path mapping on the Path Mappings page instead. Make sure the mapping you create covers the actual location of the bit.cpp file. If you are not sure, please let us know:

• The full path of the ../src/bit/bit.cpp file on Linux.
• The full path bit.cpp file on Windows.

We can then help you get the mappings working. Note that if N: is a Linux network share, you can simply map N:\ to the Linux path of that share using the Path Mappings page. It will automatically cover all paths inside N:.

[support]

No worries, the new OpenOCD package should automatically detect and handle both Picoprobe v1 and v2.

[support]

Hi,

We can gladly investigate and fix it for you, however it looks like your support period has expired a while ago. We would kindly ask you to renew your key here and try out the latest version. If the problem persists, please let us know, and we should be able to fix it within 2-3 business days.

[support]

Hi,

Thanks, we have rechecked everything on our side. It looks like you are using the Picoprobe v2 firmware, that uses the CMSIS-DAP protocol. It requires selecting CMSIS-DAP instead of Picoprobe in OpenOCD settings.

We have released an updated OpenOCD package that will detect it automatically. Please feel free to install it via VisualGDB Package Manager, and your picoprobe will appear in the USB Devices list as expected.

[support]

Hi,

Thanks for sharing the screenshots. The adapter speed command should not be related to the “could not open device” error, however another setting is. According to your screenshot, you have selected the Debug Methods mode instead of USB Devices mode in the “Debug Using” field. This means that VisualGDB would expect you to install the probe drivers yourself.

If you switch back to the USB Devices mode, VisualGDB will let you pick a specific probe and will suggest installing the correct USB driver for it.

If it works now, you have likely installed the driver as a part of your troubleshooting steps, so both the regular OpenOCD and VisualGDB’s OpenOCD should work.

[support]

Hi,

It looks like the drivers for the picoprobe are configured incorrectly. If you could post a screenshot of the Debug Settings page of VisualGDB Project Properties, and another one of the Help->About VisualGDB window, we will try to suggest a few things.

[support]

Hi,

This looks like the project you are trying to debug is referencing a non-existent debug method. Please try opening VisualGDB Project Properties and double-check the debug settings there. If VisualGDB suggests installing missing packages (e.g. OpenOCD), please proceed with installing them.

P.S. VisualGDB was supposed to show a more informative error message in this case, but due to a bug it reverted to a rather generic one. We have fixed it on our side and will include the fix in the next maintenance release.

[support]

No problem.

If the clean didn’t work, the project might have been using custom clean rules, expecting the object files to be in that location. Either way, disabling the Preserve Subdirectories for Object files setting would fully restore the old behavior.

The easiest way to get the paths working would be to add a mapping to VisualGDB Project Properties -> Path Mappings. We would advise proceeding like this:

1. Start with a specific source file that is not working. Take a note of its path on Windows (e.g. c:\projects\shared\test.cpp) and on Linux (e.g. /home/test/shared/test.cpp).
2. Add a mapping to the Path Mappings page covering just the file directory (e.g. c:\projects\shared => /home/test/shared).
3. If you have multiple project files, make sure you edited the correct one. To avoid confusion, we would advise temporarily unloading other projects from the solution.
4. Confirm that the mapping fully fixed the problem for this file.
5. Once the problem is fixed, try changing the mapping to be as generic as possible (e.g. c:\projects => /home/test) and adding it to other projects.

There might be an easier way to get it working (e.g. using the Synchronized Directories page). If you could give us a brief description of your directory structure (i.e. why are some files located outside the project regular folders, and how do you usually synchronize them between Windows and Linux), we can try to suggest a more universal way to handle it.

[support]

No problem, please try attaching a debugger to the devenv.exe process and capturing a stack trace of the crash as shown here:  https://visualgdb.com/support/callstack

[support]

Hi,

Sure, you can change it on the first page of VisualGDB project Properties, next to the toolchain selector.

[support]

Hi,

No problem, we can help you get it working. The issues you are describing are likely caused by 2 changes from VisualGDB 5.4 to 5.6:

1. Instead of placing all object files into 1 directory, VisualGDB 5.6 tries to place them into respective subdirectories. This allows building projects that have multiple files with the same name (e.g. subdir1\source.cpp => build\<…>\subdir1\source.obj  vs. subdir2\source.cpp => build\<…>\subdir2\source.obj). If you build the old project with VisualGDB 5.4, all object files will be placed directly in build\<…>. If you then open it with VisualGDB 5.6, it will indeed expect the object files to be in subdirectories and won’t remove them from the old location.
   There are 2 workarounds to this issue:
   1. You can set the VS Project Properties -> General -> Preserve Subdirectories for Object Files to False to restore the old logic for placing object files. The project will work the same way as it did for VisualGDB 5.4, although having multiple sources with the same name won’t be possible.
   2. You can manually clean the object directories (remotely and locally) when switching from v5.4 to v5.6. This is only needed once – after you build the project with VisualGDB 5.6, it will be able to locate and clean the object files just fine.
2.  When dealing with the source files outside the project directory (not covered by any path mapping rules), VisualGDB 5.4 assumes that the relative path on the Linux side would be the same as on the Windows side (e.g. if a project located c:\projects\app is mapped to /home/test/app references ../shared/tool.cpp, VisualGDB would map it to /home/shared/tool.cpp). This caused weird errors for users that had different path layouts on Windows and Linux sides, and if some additional MSBuild rules translated the relative path to absolute, so we changed the path mapping logic as follows:
   1. First, VisualGDB would resolve the relative path to absolute one (e.g. c:\projects\shared\tool.cpp).
   2. Then, it would explicitly check the path mapping rules for a rule covering this path. The following locations are checked:
      • Main source transfer command defined in VisualGDB Project Properties -> Project Settings.
      • Additional path mappings from VisualGDB Project Properties -> Path Mappings.
      • Additional custom source directories (VisualGDB Project Properties -> Synchronized Directories).
      • Additional directory transfer actions in VisualGDB Project Properties -> Custom Build Steps).

   If you are switching from VisualGDB 5.4, please try locating the sources files in question on the Windows machine, and then make sure their directory is covered by one of the settings listed above (e.g. you can add a path mapping from c:\projects to /home/test to cover anything inside c:\projects and any of its subdirectories).

Also if you have a complex project structure involving multiple applications and libraries, please consider switching to Advanced CMake. It allows having just one VisualGDB-level project (with one copy of source transfer settings, debug settings, etc.) with multiple applications, libraries and other custom targets, dramatically reducing the duplication of settings between applications and libraries.

[support]

No problem, and good to know it worked.

[support]

Hi,

VisualGDB manages the STM8 debugging via OpenOCD – an open-source tool for interfacing gdb to various hardware debuggers. The STM8-specific logic is contributed by ST and is mostly located in the stm8.c file.

If you would like to change how OpenOCD handles the reset sequence, we would advise first locating the related logic in the OpenOCD sources. If there is an existing option for changing it, you can try adding it to the relevant OpenOCD script, or directly to the command line (use VisualGDB Project Properties -> Debug Settings -> Advanced to edit the OpenOCD command line directly). If there is no such option, you would need to patch OpenOCD and build a modified version yourself. We would advise following this tutorial to build our OpenOCD fork – it uses CMake and is much easier to build  on Windows, compared to the mainline version.

If you end up patching OpenOCD to fix the issue, feel free to either submit a pull request to us, or send a patch to the OpenOCD mailing list, so that your patch gets included in subsequent releases.

[support]

Hi,

No problem, we will try to help you. The symbolic link error could be caused by your antivirus interfering with the Visual Studio process, or by invalid symlinks on the target.

The easiest way to track it down would be to enable the SysprogsSync logging via Tools->Options->VisualGDB->General->SSH->Log SysprogsSync Transfers. Once you try resynchronizing the directory again, VisualGDB will create a SysprogsSync.log file on the Windows side containing the detailed information about the transfer. Please try focusing on a single symlink that could not be set, and checking:

1. Whether its value on the Linux side makes sense
2. Whether the target file/directory got copied to the Windows side
3. Whether the log file mentions anything particular about that symlink

If it doesn’t help, please share your findings along with the relevant parts of the log file, and we will try to help you get it working.

[support]

Thanks for confirming your license information.

VisualGDB displays the XMing GUI whenever any program running on the Linux side tries to connect to the X11 server in order to display the X11 GUI via SSH. Normally, it happens when explicitly running graphical Linux applications. Sometimes, the command-line tools try connecting to the X11 server as a part of initializing some libraries, that also triggers this GUI.

If you would like to find the root cause, you can try enumerating the processes on the Linux machine while the VisualGDB XMing prompt is still active, attaching to the suspect ones and checking the call stack. It should explain which process is trying to connect to X11.

A more universal solution would be to completely disable X11 forwarding for that host via Tools->VisualGDB->SSH Host Manager->Host-wide settings->X11 forwarding = Disabled.

[Author]

Posts