Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
VisualGDB does not cache the headers from the WSL, instead it configures the IntelliSense to directly look inside the WSL directories.
If you are using CMake on WSL, you may be affected by a bug that prevents VisualGDB from querying CMakeLists.txt properly. If this is the case, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1375.msi
support
KeymasterHi,
We have rechecked the sample project and it had 2 references to the system_stm32f0xx.c file: one from the BSP and another one from the STM32CubeMX project.
Please remove the reference to the one from the BSP via VisualGDB Project Properties -> Embedded Frameworks -> Default System file, then rebuild the project (Build->Rebuild All). This should get the build to work.
support
KeymasterNo problem. Let us know if you need advice on interpreting the section offsets/sizes.
support
KeymasterHi,
We had it available as an option and less than 1% of our users actually enabled it (still causing troubles due to spamfilters). Sorry.
Regarding the on-page notifications, you can get a brief overview of the recent replies by clicking on your username near the post and then selecting “topics” (e.g. https://sysprogs.com/w/forums/users/bmcdonnell_psi/topics/). Each topic will show the last post time.
We understand that this may not be the most usable way to display topics and updates, but due to priority constraints we have to rely on the existing forum engine without doing serious modifications to it.
support
KeymasterHi,
Sorry for the delayed reply. We have reviewed the process of making a custom cycle counter driver for real-time watch and profiler and published a detailed tutorial here: https://visualgdb.com/tutorials/profiler/realtime/cyclecnt/
Let us know if you encounter any troubles with it.
We also recommend updating your profiler package via VisualGDB Package Manager and using the latest pre-release build of VisualGDB: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1374.msi
support
KeymasterHi,
Thanks, we have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1374.msi
February 2, 2017 at 06:25 in reply to: including startup_stm32*.c in project without absolute path #10280support
KeymasterHi,
Unfortunately the Visual Studio extensibility API cannot handle variables in .cpp file paths properly, so VisualGDB has to use relative paths with the user name.
It will automatically update those paths if you open the project on a different machine where the paths are different. Another option would be to relocate the BSP to a location under the source control (see this tutorial). Then VisualGDB will use relative path to that location.
support
KeymasterHi,
Most likely something went wrong with the alignment and one of the sections ended up not being aligned properly. Running “arm-eabi-objdump -h <ELF file>” and checking the section addresses and sizes could explain what could be wrong.
support
Keymastersupport
KeymasterHi,
You can click on your username in the left column of the original post to view the stats page.
We do realize the importance of the feature, however when it was enabled, it was used by less than 1% of users and was causing constant disruptions due to mail server issues. If you want to get instant notifications per email, please consider using the support form.
As we rely on an existing forum engine, we have to live with some limitations imposed by it, like lack of efficient mechanism of attaching images. We understand the inconvenience caused by it and we may eventually address it, but currently we are prioritizing work on VisualGDB features over this.
support
KeymasterThanks for reporting this, we have improved our support for format specifiers in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1370.msi
support
KeymasterHi,
Looks like you have first imported the system_stm32f0xx.c file to the project and then deleted it. Please either remove the non-existing file from Solution Explorer, or restore it on the disk.
support
KeymasterHi,
Please try enabling the verbose mode via Tools->Options->VisualGDB->General and try building again using the TAR mode. The log should should which files failed to transfer. Most likely this is related to some sort of a file permission problem.
support
KeymasterHi,
The easiest way to fix that is to use the VisualGDB header discovery feature to quickly locate the stm32f0xx_hal_conf.h file (should be somewhere in the project folder) and adjust the build settings automatically.
support
KeymasterHi,
Yes, please check the Output window (View->Output). It should contain the detailed build log listing all errors printed by the compiler, linker and other tools. If you are not sure, please post the log contents here and we will help.
-
AuthorPosts