Forum Replies Created
-
Posts
-
Hi,
No problem,we have rechecked it. Indeed, Espressif has moved the definition of the CPU-specific settings in a way that VisualGDB couldn’t properly parse. We have updated VisualGDB to handle it properly: VisualGDB-5.6.109.4807.msi
Hi,
For ESP-IDF projects, VisualGDB works as a front-end to the regular ESP-IDF build system. I.e. it provides convenient GUI for managing common ESP-IDF settings and tasks, but lets the normal ESP-IDF build scripts handle all the building. E.g. when you add a file to Solution Explorer, VisualGDB would update the idf_component_register() in CMakeLists.txt, but will still let the ESP-IDF handle the actual build, as if you edited the statement manually.
There is no special GUI setting for importing external components made for ESP-IDF 4.4.1 and automatically porting them to work with ESP-IDF 5.0. You would need to manually add them to the project by editing the relevant CMakelists.txt files (see the ESP-IDF documentation for specific instructions), and possibly porting them to the new ESP-IDF 5.0. VisualGDB cannot do this work automatically, but it can make it easier by providing powerful IntelliSense and debugging functionality that will help you navigate the unknown code base faster.
The sdkconfig file contains the values of the parameters, but not their descriptions. The actual descriptions are stored in the KConfig files scattered across the ESP-IDF folder. VisualGDB parses them, combines the result in a convenient searchable tree, fills it with values from sdkconfig and displays it on the first page of VisualGDB Project Properties.
Different ESP-IDF versions can have slightly different setting layouts (e.g. a the same setting could be called differently) and VisualGDB Project Properties would reflect it.
We can double-check the CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ setting on ESP-IDF 5 if you could share a screenshot of your Help->About VisualGDB window to make sure we are looking at the same thing.
If the inner VS instance crashes without reporting anything to the outer one, you have likely selected an incorrect debug engine when attaching the outer VS instance to it.
Please try selecting both “Native” and “Managed (.Net 4.x)” as the debug engines in the Attach dialog. This should catch crashes caused by both managed and native code.
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.
