Forum Replies Created
-
Posts
-
Hi,
These settings come directly from the ESP-IDF framework (you can verify this by running the menuconfig command manually as described here). They can differ between different devices and different ESP-IDF versions. If you need help locating a specific option, the best way would be to search the ESP-IDF documentation, ask on the Espressif forum, or look for ESP-IDF examples that could be using that setting.
Hi,
This typically happens for complex projects using custom toolchains – some of the implicit macros set by the compiler do not get properly passed to the VisualGDB’s IntelliSense engine, and prevent IntelliSense from finding the relevant function definitions in the headers.
In order to track it down, please follow the steps below:
- Isolate the problem to a minimal project with just one source file, one function (e.g. void test123() {…}) and as little #include<> directives as possible.
- Manually the actual definition of the missing method by searching the header files.
- Try opening that header file in Visual Studio and see if the relevant definition is grayed out. If it is, check for conditional statement (#if <…>) that could be blocking it.
- If you have found the relevant conditional statement (e.g. #ifdef SOME_FEATURE), you can manually pass it to the IntelliSense engine via VisualGDB Project Properties -> IntelliSense Settings -> Additional CFLAGS (the flag in this example would be -DSOME_FEATURE or -DSOME_FEATURE=123).
- If the statement is not grayed out, try moving the test() function directly in the header file, as close to the definition as possible. If it works from there, some code after the definition is interfering with IntelliSense. Moving the test123() function to different parts of the header file (or further down the #include<> stack) should help isolate the part causing the problem.
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
