Forum Replies Created
-
Posts
-
We did actually use LOADADDR in our tests and the new generator – this is the proper documented way to get the load address of a section (i.e. the location of the section values stored in FLASH) and it worked reliably in several different configurations.
The Embedded Memory Explorer is a part of our pre-release integration tests, so most likely the issue is caused by corrupt settings of one specific project. Please try checking if the memory explorer works for a newly created “LEDBlink project” (don’t forget to build it first) and if it does – try comparing the settings of the 2 projects. Alternatively please try building/debugging the broken project or opening VisualGDB Project Properties for it – you will likely get a more specific error message if some of the settings are corrupt.
No worries, we have closed the ticket as a duplicate, linking it to this forum thread.
BTW, we use the same internal system for handling inquiries received via forum and via the support interface, hence there is need to create both a forum post and a support ticket – all we can do in this case is to link one inquiry to the other one. Simply use the communication method that is the most convenient for you and we will try to respond to your inquiry as soon as we can.
Good to know it works. Generally, we would not move commonly used commands like this to non-intuitive locations, so if anyone else encounters missing commands, please double-check that the VisualGDB extension is properly loaded into Visual Studio as shown in this page: http://visualgdb.com/support/loadfail/
According to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.
Please note that installing VisualGDB on another PC, editing registry to affect the trial counter, or creating further forum accounts does not reset your trial period from the support point of view.
As providing quality technical support for our users requires continuous effort on our side, we do expect our users to play fair and are not able to offer any help once the original trial period expires.
Thanks for the clarification. There is already an option for this under Tools->Options->Text Editor->C/C++ (VisualGDB)->Advanced->Code Completion->Suggest names while typing.
If the option is disabled, you can invoke the suggestion menu explicitly via Edit->IntelliSense->Complete Word command (Ctrl-Space) which is standard for all Visual Studio project types.
Please try updating to the latest VisualGDB 5.4R3.
Also, according to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.
Thanks for the detailed feedback. It will take us a couple of days to properly process it, come up with hotfixes for easily resolved issues and give time estimates on bigger ones. Please expect an update on this around the middle of the next week.
No problem. We have changed the logic that fetches the item names for the navigation bar to use exactly the syntax they are declared with. Please try this build: VisualGDB-5.4.103.3013.msi
Thanks for the video. We have confirmed the issue and it looks like it is introduced by some recent changes in the latest Visual Studio 2019 update that we haven’t fully tested yet.
We will investigate this and will try to publish a hotfix in the next 1-2 weeks.
Sorry, the .vgdbcmake file did not get attached properly. We have just patched the forum engine on our side, so you should be able to upload it again.
We have also rechecked this on a newly created project and it did get cleant correctly. VisualGDB does have an option to remove the entire remote source directory on clean, however it is hidden and ignored for projects that are using direct SSH file access.
Please try attaching the .vgdbcmake file again and we will check what is going on.
Hi,
As VisualGDB supports many different build systems, its custom action logic treats build as a single “black box” step, hence they will indeed run after the build regardless of the actual steps performed during the build. If you would like a finer-grain control over this, we would advise creating custom targets with the build system you are using (e.g. see this tutorial for custom MSBuild targets) or try searching CMake documentation if you are using CMake (stripping symbols is a fairly common task, so there might be ready-to-use snippets posted on StackOverflow or other forums).
If you don’t want to modify the build system settings, please consider changing your file structure so that the custom actions won’t overwrite any files. E.g. copy $(TargetPath) to $(TargetPath).target, then move debug symbols to $(TargetPath).debug and finally strip $(TargetPath).target. You would need to update the debug and deployment settings to deploy/launch $(TargetPath).target instead of $(TargetPath), but as long as you do that, the building and debugging will work as expected and the symbols won’t get lost.
This looks like you have updated the VisualGDB binaries, but might be still using the MSBuild targets files from the old version. Please double-check that the project builds with VisualGDB 5.4 from Visual Studio and that the SysprogsPlatform.targets and other MSBuild files on the TFS machine match the corresponding files on the machine where the build succeeds.
No problem. We have investigated this and confirm that the syntax used in the VisualGDB-supplied linker scripts indeed does not check for FLASH overflow when placing the initialization data for RAM sections.
We have done several tests with the “> SRAM AT > FLASH” syntax and confirm that it solves the problem and is otherwise equivalent to the old one, so we have updated our linker script generation tool to use the new syntax and also changed the logic used by the “Additional Memories” page in VisualGDB.
The next STM32 BSP update will include the linker scripts using the new syntax. As a workaround until then, please consider editing them manually, although the only difference in behavior would be the error message for FLASH overflows caused by the RAM initialization data (regular FLASH and RAM overflows are still reported correctly with both linker script versions).
Thanks for providing detailed repro steps and sorry for the confusion – we have previously encountered many cases when the unexpected image layout was caused by optimization and have never received any reports on issues caused by the VisualGDB’s linker script format.
