Forum Replies Created
-
Posts
-
Hi,
This looks like something on the Visual Studio level and not on VisualGDB level. Please try checking if the same happens for a regular Win32 C++ project that is not based on VisualGDB.
If you can confirm that the problem is specific to VisualGDB projects, we can help you resolve it, however we would kindly ask to renew your support first, as it has currently expired.
Hi,
Sorry, as the STM32 drivers come directly from ST and are not maintained by us, the support we can provide here is somewhat limited.
Please try reproducing the problem with a new project created from scratch (by selecting the “STM32CubeMX Samples” in the wizard). If it persists, please consider submitting a bugreport to ST (you can find the SDK version used by each BSP in the SDKVersions.xml file).
If the problem does not happen on a new project, most likely the new SDK has introduced new configuration parameters, or changed some APIs, and the project would need to be updated accordingly. Comparing the project code with the freshly cloned sample project should be a good starting point.
Hi,
Normally, using the VisualGDB.exe /runtests <container> command line would automatically program the memory, run the tests and save the results.
If you are not using the VisualGDB test frameworks, you can also use the VisualGDB.exe /launch <vgdbsettings file> syntax as an equivalent of the “run without debugging” command in Visual Studio.
Finally, Segger J-Link might have its own set of commands for scripting FLASH memory programming. Feel free to double-check their documentation, it may contain some relevant examples.
Hi,
Please follow the instructions described on this page. They go through the most common causes of this problem.
If nothing helps, please let us know more details (per instructions) and we will help you get it to work.
Hi,
Looks like you are using a VisualGDB edition that does not support hardware tracing.
The J-Trace functionality is supported starting from the Custom edition. You can always upgrade your existing license via this page. If you would like to try it before upgrading, please contact our sales for a trial extension voucher.
No problem, we can help you. Could you please share the screenshots of the Debug Settings page and the Embedded Debug Tweaking pages so that we could look into this?
Hi,
It looks like your machine is missing some packages. Please try updating to VisualGDB 5.5 Preview 2. It will automatically install the missing packages on project load.
Yes, that’s the correct option and thanks for sharing the screenshot. Sorry for being non-specific, we thought suggesting the general direction immediately would be more useful than putting this through the repro queue in order to produce an exact screenshot on our side.
Hi,
Sorry, this is a known limitation of the latest Raspberry Pi toolchain. It no longer supports QMake due to internal changes in the toolchain structure.
Please try updating to VisualGDB 5.5 Preview 2 and creating a Qt-based project as shown here: https://visualgdb.com/tutorials/linux/qt/cmake/
Yes, there is a setting in VisualGDB Project Properties -> Embedded Debug Tweaking that allows doing that. If you cannot find it, please let us know and we will post more details on Monday.
This is actually by design. Most IDEs (including Visual Studio) require the include search paths to be specified explicitly (deriving them implicitly tends to cause very hard-to-track errors if you have multiple headers with the same name in different directories).
Adding headers to Solution Explorer will normally not affect the build at all – the only reason for adding them is to make them easily accessible via Solution Explorer.
That said, for MSBuild-based projects you can enable automatic include path computation based on header files in Solution Explorer (VS Project Properties -> General -> Header Search Paths -> Compute Include Paths Automatically), although we would not recommend using this option in production code to avoid confusing headers with the same name.
Hi,
Strange, we have tried importing the project, but could not reproduce the issue. The _FPU_PRESENT macro was successfully imported as a preprocessor macro, so it is hard to say why it would not work on your side.
If the entire project is not confidential, please consider sending it to us as well. If it is, please follow the steps below to gather the required information on your side:
- Try importing it as an MSBuild-based project (ensure you use VisualGDB 5.5 Preview 2) and build it.
- The error window will show the specific .cpp file that is triggering the error. Make sure you can locate this file in Solution Explorer.
- Locate the .rsp file corresponding to the .cpp file in the VisualGDB\Debug subfolder. It will contain the command line passed to gcc by VisualGDB.
- Run the following command line from the project’s directory: <full path to arm-none-eabi-gcc.exe> @VisualGDB\Debug\<rsp file> and confirm that the error can be reproduced.
- Send us the .vcxproj file, the .rsp file and the exact error message produced by gcc and we should be able to find the root cause and fix the importing logic accordingly.
P.S. Based on a quick look, QP looks like a great, although very niche framework. Hence it would only be relevant for a small fraction of VisualGDB users and fully integrating it with VisualGDB would have a much lower priority than many other queued features. That said, we can always do it as a custom paid feature if anyone is willing to cover the integration costs directly. Feel free to reach out to our sales to get a quote.
Hi,
It looks like a preprocessor macro got incorrectly converted into a source or an include file.
Most likely, our importer plugin is not handling some combination of settings correctly. If you could send us the original project file you are trying to import (.uvproj + .uvopt files), we should be able to investigate and fix this.
Hi,
70 KB is still orders of magnitude less than a typical Linux kernel + rootfs, so VisualKernel does not provide any special GUI for removing the debug symbols from the built modules.
That said, you can always remove the symbols from the built module by running the strip tool (you can conveniently use the custom post-build actions if you would like to automate it).
