Forum Replies Created
-
Posts
-
Yes, starting from VisualGDB 5.x, you can import the STM32CubeIDE projects directly using the STM32CubeIDE import plugin.
Sorry, could you please post a screenshot of the entire VS window as well. It really shows a lot of important information about the state of the Clang engine (see this explanation). Otherwise, it’s virtually impossible to guess what is going on.
Second of all, does the problem happen with GPIO_PIN_Reset? If yes, please try the following:
- Try simplifying the expression as much as possible. E.g. “int x = GPIO_PIN_Reset”. Does this still reproduce the problem? If not, is there any specific change between the repro code and the “int x” example that changes the behavior?
- If the simple case still triggers the problem, does moving right after the preamble (i.e. block of #include<>’s) change anything?
- What happens if you add another enum (not just another value to an existing enum) near the place where GPIO_PIN_Reset is defined? Will it trigger the problem as well?
- If yes, what if you move the newly added enum to the source file that triggers the problem (try putting it before and after the #include<> block)?
Hi,
We would advise creating a VisualKernel project for the kernel itself (see this tutorial). First of all, this will allow building and installing the kernel directly from Visual Studio.
Second of all, all you would need to do when creating a new kernel module, is to select “My Kernel is built with VisualKernel” and point it to the Kernel project file. This will automatically handle build paths, versions and source file mappings (see this tutorial).
Thanks for confirming your license key.
The “Exclude from build” setting works out-of-the-box for MSBuild-based projects only. In order to achieve the same effect with GNU Make-based projects, we can advise one of the 2 workarounds:
- You can manually use the $(filter-out …) expression combined with ifeq($(CONFIG), DEBUG) to filter out specific files from the source file list (see how this is handled for STARTUPFILES). VisualGDB will preserve your changes to the Makefile, although they won’t be synchronized with the VS-level “exclude from project” setting.
- Alternatively, simply surround the code in your source files with #ifdef DEBUG (or any other macro used in your project to distinguish debug/release configurations).
Most likely, the *.xml is not mentioned in the copied file masks. If you could share a screenshot of your settings, we should be able check this and help you find the cause.
The return code of 0 means that the there was no critical error preventing VisualGDB from launching the tests. You can find out the specific tests that succeeded/failed by analyzing the report file generated by either /output or /vsoutput option (see this thread).
If this doesn’t help, please let us know what exactly you are trying to accomplish and we will try to suggest the best setup for it.
Hi,
Although VisualGDB cannot directly generate a Junit-compatible output, it can be configured to generate the outputs in the Visual Studio/MSTest test report format.
You can do this via the following command line
VisualGDB.exe /runtests <...> /vsoutput:<output file>
As both JUnit and MSTest test report formats are very popular, there are various open-source translators between them, so we would advise simply running one of them after VisualGDB returns.
It looks like you are not using the ESP-IDF component GUI. Please ensure you use the Advanced ESP-IDF project wizard as suggested by VisualGDB and shown in this tutorial.
Unfortunately we are not able to guarantee that every possible combination of Arduino targets and libraries will work. Please consider posting on the Arduino forums for further support.
We have determined that the problem occurs in a 3rd-party component: OpenOCD. Please contact OpenOCD support for further help with this.
Hi,
We are currently preparing a tutorial on the multi-core STM32 devices, so if the time permits, please consider waiting for 1-2 weeks and we will publish detailed steps to get it working.
Although debugging both cores within the same debug session is not possible due to gdb limitations, it should be possible to debug them from 2 independent Visual Studio instances, as long as your debug probe supports it.
If you need to get started faster, please consider creating a project using STM32CubeMX and importing into VisualGDB and then debugging it with Segger J-Link. The J-Link debug probe comes with its own low-level software that works out-of-the-box with multi-core devices and requires no special configuration.
Hi,
If you are using MSBuild, the output verbosity is controlled by Visual Studio itself and can be configured via Tools->Options->Projects and Solutions->Build and Run.
You can also find the preprocessor macros in the .rsp files inside your build directory (search for -D<macro> strings).
Normally, something like this would work:
#ifdef STM32L431CC Report.DeviceType = MyIDForSTM32L431CC; #elif defined (...) Report.DeviceType = MyIDForSomethingElse; #else #error Unknown device. Add a check for it above. #endif
Hi,
Sorry, the latest ARM toolchain (gcc 9.2.0) is based on the official GNUARM toolchain and does not contain automatically discoverable source packages.
We are planning to address this in one of the next toolchain updates, however currently the workaround would be to either download the sources from the ARM site manually, or to switch back to gcc 7.x that includes the automatic source packages.
Thanks for renewing your support. VisualGDB indeed has an IntelliSense cache located in the CodeDB directory (the exact location depends on the project type). Please try closing the solution, deleting the CodeDB directory and reopening it.
If it doesn’t help, please clarify what exactly do you mean by “all links are lost”. If you could attach a screenshot highlighting the problem, it should be easy for us to understand what is going on and suggest a more specific solution.
