Forum Replies Created
-
AuthorPosts
-
June 5, 2019 at 00:36 in reply to: x_display = XOpenDisplay(NULL); returns NULL on latest UBUNTU systems #25060
support
KeymasterSorry, this is not something managed by VisualGDB, so it’s hard to give any specific advice. Please refer to the Linux and X11 documentation.
support
KeymasterJust wanted to let you know that we have updated VisualGDB to detect the gcc version for the GNUARM toolchains and also to show all discovered versions of the toolchain instead of just the latest one.
Please feel free to try this build: VisualGDB-5.4.106.3173.msi
support
KeymasterHi,
VisualGDB already supports selecting arbitrary ESP-IDF checkouts to use with your projects. Please use VisualGDB Project Properties -> ESP-IDF Project -> ESP-IDF Checkout to select a version you would like to use (VisualGDB can automatically clone IDF releases from Github).
We are also working on an update to our ESP32 toolchain that will include a newer IDF checkout.
support
KeymasterHi,
If you are using clang-format, please use our graphical format file editor to change the line break logic. If you cannot find a specific setting, please refer to the clang-format documentation here for an exhaustive list of formatting settings.
support
KeymasterThanks for the update. It indeed looks like Espressif has ported their OpenOCD fork to a newer OpenOCD version, adding support for more devices.
We have merged these changes into our branch and released an updated debug package. Please update it via Tools->VisualGDB->Manage VisualGDB Packages.
support
KeymasterHi,
Please check whether the code formatting for your project is managed by clang-format, or the legacy formatting engine. If a formatting icon appears in the top right corner of the text editor, the file is managed by clang-format and the formatting behavior can be configured by clicking at this icon. For legacy formatting engine, you can use Tools->Options->Text Editor->C/C++ (VisualGDB)->Formatting.
If you are not sure, please send us a screenshot of your Visual Studio window having the source file open and we will provide you with more detailed steps.
support
KeymasterGood to know the entry point works.
Regarding bootloader.bin, please try enabling verbose logging via Tools->Options->Projects and Solutions->Build and Run->MSBuild Project Output Verbosity -> Diagnostic.
This should produce a detailed build log showing the project build order and also when the .bin file is generated and when it is used by another project. If it doesn’t help, please feel free to post it here and we will try to help you get it to work.
support
KeymasterHi,
Sorry, we don’t have a ready-to-use driver for the Parallel NOR FLASH, however you should be able to create your own plugin for NOR FLASH based on our QSPI plugin (see this tutorial). You may also want to check with Segger support whether they have ready-to-use J-Link-specific plugins for this memory type.
support
KeymasterHi,
The easiest way to create the project structure you described would be to create the regular Application projects and then edit the .pro files, manually switching their type to libraries.
However for advanced Qt-based projects, we would advise using either MSBuild or CMake. Although this requires extra initial setup, such setup would be much more scalable due to better integration with VS.
May 29, 2019 at 15:57 in reply to: How to let the visual GDB find the -DCMAKE_INCLUDE_PATH first? #25032support
KeymasterPlease let us know how exactly you observe the difference in the behavior (see the 3-step description format). This should help us understand what is going on and suggest steps to fix it.
support
KeymasterHi,
Please try restarting your computer. If it doesn’t help, please try comparing the OpenOCD command lines used with Visual Studio Code and with VisualGDB. Ensure that you are using the same scripts and other command line arguments in both modes.
If all the options are the same, please try running the VisualGDB’s OpenOCD manually with the command line shown in the log and then try connecting the esp32 GDB to it (target remote :<port>) and let us know what happens then.
May 28, 2019 at 18:33 in reply to: How to let the visual GDB find the -DCMAKE_INCLUDE_PATH first? #25024support
KeymasterHi,
Normally, GCC would handle the system include directories automatically, so VisualGDB does not offer any special settings for overriding this.
You could try adding the -nostdinc option to CFLAGS and then entering all include directories (system and regular) in the order you are trying to use, however we would advise against this, as such setup would be very fragile and could stop working if the internal directory structure of the toolchain changes in the next GCC version.
support
KeymasterHi,
This looks like something managed by the ESP8266 SDK itself and not by VisualGDB. Please consider asking on the Espressif’s forum instead.
support
KeymasterWe are aware of the -dumpversion switch, however the GNUARM toolchain location logic does not utilize it because the version does not affect anything other than the toolchain selector.
You can override the version by manually editing the toolchain.xml file (either in the toolchain folder or under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles after importing the toolchain. All other files containing the toolchain version are generated based on it.
support
KeymasterSorry, this is a side effect of the registry-based toolchain discovery. The toolchain should work correctly, however the tool versions shown in the toolchain selector will indeed be incorrect.
As a workaround, please try importing the toolchain manually by clicking “Locate toolchain by finding the gdb executable” in the toolchain selector.
-
AuthorPosts