Forum Replies Created
-
Posts
-
Please try attaching another instance of Visual Studio to the one causing memory leaks (ensure you have the ‘auto’ selection for debugging engines). Then select Debug->Windows->Show Diagnostic Tools and switch to Memory View. Start your work session and do the regular work tasks for about 5 minutes. Then click the “Take snapshot” button in the Memory view of the Diagnostic tools and work for another 10 minutes. Then click “Take snapshot again” and wait for the updated line to appear.
Finally click on the difference between the memory snapshots (see the attached file) and share a screenshot of the snapshot window that will open up. It will list the exact memory differences between the 2 snapshots, showing what has consumed the memory.
Hi,
It looks like the ‘*’ frame around the comment is interfering with the comment parsing logic.
Please ensure that the line containing the ‘@param’ comment does not have any other characters (other then spaces) in front of the @param part and VisualGDB will handle it correctly.
Good to know it works. BTW, you can also force VisualGDB to clear the BSP-related caches and reload all package definitions by opening and closing the Tools->VisualGDB->Manage VisualGDB Packages window.
Thanks for reporting this. It turns out, VisualGDB incorrectly substituted VisualGDB-level variables that are not available on the MSBuild level.
Please try using the relative path (from the .vcxproj file’s directory) instead.
You can also try this VisualGDB build that will not substitute unsupported variables when editing settings via VisualGDB Project Properties: VisualGDB-5.4.105.3146.msi
Strange. Have you tried regenerating those files via the first page of VisualGDB Project Properties after moving the BSP and restarting VS? If this didn’t help, could you please try creating a new project based on the BSP and then share a file that was generated using the incorrect paths? This should help us narrow the issue down and release a hotfix ASAP.
Thanks for sharing this and good to know it works. We would still advise setting the AGENT_WORKFOLDER variable, as it would suppress various interactive prompts (e.g. about activating the new version after an update, or installing missing toolchains/BSPs).
Sorry, Visual Assist only works with regular VC++ projects (i.e. Embedded Project Wizard) and not with advanced projects such as the new ESP-IDF project type, as those projects are not based on VC++ and Visual Assist does not know how to attach to them.
You can use the regular Tools->Options->Environment->Fonts and Colors to modify the syntax highlighting colors for both regular C/C++ and VisualGDB-based projects.
If you are missing some fine-grain highlighting rules/settings, please feel free to let us know. The code highlighting for ESP-IDF projects is fully managed by VisualGDB, so we might be able to add a few extra cases there as long as it doesn’t require a major change on our side.
Most likely, VisualGDB was not activated on the machine/account where you are running the build and hence it tries to display the key prompt.
The easiest way to get it to work would be to ensure you can build the projects manually on the same machine using the same user account.
We would also advise setting the AGENT_WORKFOLDER environment variable (used by TFS) to a non-empty value so that VisualGDB will activate the unattended mode, reducing the amount of prompts and GUI.
If this doesn’t help, please let us know and we will help you get it to work.
Sorry, the IntelliSense behavior looks correct. You can double-check this by completing the expression manually and checking whether the code compiles without errors. If it does, but VisualGDB still doesn’t suggest it, please let us know.
Hi,
If you are using OpenOCD, please try adding the mon flash write_image command to the gdb startup commands.
Please let us know the email associated with your license key so that we could check your support status.
Most likely you have accidentally installed a newer version of the ESP-IDF (the pre-release versions are very, very buggy, so we generally recommend using official releases only). Please try deleting and reinstalling the ESP32 toolchain via Tools->VisualGDB->Manage VisualGDB Packages.
Sorry, we still need a specific sequence of steps that could reproduce the problem on our side in order to do anything about it. Generally, C# and C++ use completely different underlying mechanisms in Visual Studio, so it could be triggered by something completely different.
The only other similar issue known to us is that running debug sessions with large amounts of live variables would leak memory due to a bug in VS (about 200 live variables with maximum refresh rate consume all available RAM in about 2-3 hours).
Sorry, the fully supported and easy-to-use way to support excluding files for specific configurations would be to switch to MSBuild. We have specifically designed our MSBuild backend to be fast and support multiple advanced scenarios and this one is definitely one of them.
The alternative procedure with $(filter-out) would involve conditionally removing specific files from the SOURCEFILES variable based on checking the current CONFIG variable, but as it is error-prone and much more fragile, we only recommend doing it if you are familiar with GNU Make internals and would otherwise advise using MSBuild.
Thanks for the update. We have reproduced the problem on our side by manually duplicating some include directories in the .rsp file so that it exceeded the 32KB limit. It looks like a different issue from the 8KB limit that is successfully solved by using the rsp files.
We will review our Nordic BSP and will try to optimize the include paths. As a workaround, please try moving the BSP into a directory with a shorter path (e.g. c:\NordicBSP) and then create a .bsplink file instead of the original directory (e.g. %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x.bsplink) that will contain the full path to the new short directory.
P.S. We have moved the reply from @MystikReasons to a separate thread to avoid confusion.
