Forum Replies Created
-
Posts
-
Hi,
This doesn’t look like a crash – it looks like you are ending the GDB session, VisualGDB sees that gdb is not responding, and shows the “GDB Command Timeout” window.
Did you obtain this call stack by manually pausing the VS process (Debug->Break all), or did it stop with an exception? In the latter case, could you share the full exception message?
Hi,
If you are just looking for the basic functionality, the Embedded version should be sufficient. If you later decide that some of the Custom features could be worthwhile, you can always upgrade your license to Custom.
As for support, we are happy to help as long as it’s within the support scope. The rule of thumb is that you should be able to get the same project working/debugging on the same hardware outside VisualGDB on your own. If this is the case, we can help you get it to work with VisualGDB as well. In this case, the command-line OpenOCD from Raspberry Pi was clearly working, and the one supplied with VisualGDB wasn’t, so it was 100% within the scope.
What usually causes frustration with support is when users come up with a rather complicated setup (custom board, tricky clock settings, sleep logic) and it starts triggering OpenOCD bugs, or otherwise interfering with debugging. Some users expect that we would go through the schematic and the datasheet with them, and help them find the exact hardware setting that would fix everything, and get upset when we ask them to first get it working with command-line gdb. Another common source of frustration is when users try to change many settings at once, get a cryptic error message coming from somewhere within the external SDK, and expect us to know how to fix it without knowing what exactly they have changed. As long as you can avoid these pitfalls, you will find our support reasonable and fast.
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:.
No worries, the new OpenOCD package should automatically detect and handle both Picoprobe v1 and v2.
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.
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.
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.
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.
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.
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:
- 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).
- Add a mapping to the Path Mappings page covering just the file directory (e.g. c:\projects\shared => /home/test/shared).
- 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.
- Confirm that the mapping fully fixed the problem for this file.
- 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.
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
Hi,
Sure, you can change it on the first page of VisualGDB project Properties, next to the toolchain selector.
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:
- 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:- 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.
- 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.
- 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:
- First, VisualGDB would resolve the relative path to absolute one (e.g. c:\projects\shared\tool.cpp).
- 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.
