Forum Replies Created
-
Posts
-
Hi,
Yes, it looks like VisualGDB is checking for modified source/header files in your project and is trying to rebuild the preamble for the newly opened file. This results in reading many header files in a short succession, likely overloading the network connection you are using and delaying the main Visual Studio thread that is trying to access the source file.
Unfortunately there’s not much to optimize on our side though – VisualGDB needs to read all those files in order to build the necessary caches and if the network connection cannot handle this responsively, it would delay everything else. The good news is that VisualGDB only does this once after you open the solution. Once the necessary data is cached, VisualGDB won’t need to recompute/recheck it again.
Also storing the source code on the Windows side (or using the direct SSH access with the Advanced CMake Project Subsystem so that VisualGDB can prioritize file accesses internally) could speed this up.
Hi,
Good to know it works. We will unify the styles of the pages after we convert most of the settings pages to WPF (they will inherit the Visual Studio color theme just like the new wizards). Before that, the WPF-based pages and WinForms-based pages will indeed look slightly differently, sorry.
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2313.msi
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2312.msi
We have added support for specifying remote host in the “Custom GDB Stub” debug mode (requires the Custom edition or higher):
You should now be able to configure your embedded project to launch OpenOCD on Raspberry Pi.
Hi,
The visual issues you are describing come from the incompatibility between the WinForms framework used by older parts of VisualGDB and the modern high-DPI displays. We are gradually switching the VisualGDB GUI to the newer WPF framework that is 100% compatible with the new displays, so we only fix the legacy WinForms GUI if it becomes completely unusable.
That said, we have recently switched the Embedded Project Properties page to WPF, please try this build (please note that it is not 100% tested and may introduce new bugs).
If the VisualGDB Project Properties window is still too large on the first run, please check the %LOCALAPPDATA%\VisualGDB\GUIPreferences.xml file and let us know if there is any correlation between the LastKnownPropertyWindowRectangle values there and the window location/size (e.g. if the stored values appear multiplied by some factor).
Hi,
Great to hear you found the memory explorer useful. There’s not much else to suggest beyond that though – commercial compilers like Keil and IAR are known to produce much smaller code, however they are costly. The only other way to reduce the footprint would be to try optimizing your code.
Hi,
If that’s the same project based on custom Makefiles (not following the regular ESP-IDF Makefile structure), many GUI features of VisualGDB won’t work properly (they rely on a specific Makefile structure of the regular ESP-IDF projects).
The breakpoint errors should be completely solvable though. Please use the “Diagnose Breakpoint Problems” button in the GDB Session window (it is explained in this tutorial, although it features an older VisualGDB version). If it doesn’t help, please create and share a full gdb log showing the exact commands sent while trying to set the breakpoints and we will advise you on the correct settings to fix this.
Hi,
No problem, we can help you with this. For MSBuild-based (and CMake-based) projects the .vgdbsettings file does not contain sufficient information to run the tests (e.g. the executable name is derived by MSBuild during compile time). VisualGDB solves this by caching those settings in a .vgdbtestcontainer file when you run the tests from the IDE.
Hence instead of running VisualGDB on the .vgdbsettings file, please run it on the .vgdbtestcontainer file as shown below:
VisualGDB /runtests <file.vgdbtestcontainer>
You can also configure VisualGDB to generate the test container file during the regular build (see the Generate a test container file property in VS Project Properties).
Hi,
Sorry, we are not able to 100% confirm it at this point. It will include the sources and examples from the original Nordic SDK, so if the mesh SDK is included in it (and works out-of-the-box), it will likely get included as well. Otherwise it would need to be treated as an external dependency.
Hi,
It is currently in development, although we did not have a chance to run our full test suite on it yet, so it’s hard to give an accurate estimate. We will likely run the final tests on it in the next 1-2 weeks and depending on the outcome, will either release it or take another 1-2 weeks to polish it up.
Hi,
One obvious thing to check would be the type of the standard library. Changing it from the regular newlib to newlib-nano (it not already enabled), would normally greatly reduce the binary size.
You could also try changing the optimization mode to “Optimize for size” via the regular VS Project Properties (not VisualGDB Project Properties).
Otherwise you would need to inspect the exact functions shown in the memory explorer and see if any of them could be removed/optimized. Enabling reference tracking in the Embedded Memory Explorer (see this tutorial) might help understanding why specific functions are included in the final binary.
Hi,
OK, thanks for clarifying your scenario with the over-the-air update. We will try to optimize this in the upcoming BSP based on SDK 15.0.
As a workaround, please create a local copy of the linker script file (sXXX_reserve.lds) and remove the SECTIONS {} part containing the .softdevice and .softdevice_sram sections. This should completely remove the softdevice sections from the final image, reducing its upload size.
Hi,
Most likely some VC++-level project properties that are used by VisualGDB to detect its projects are not set correctly. Please try holding shift while right-clicking in the Solution Explorer – this will force the VisualGDB Project Properties command to appear. Once you open the properties window, VisualGDB should show the details on any errors it detects.
Another way to diagnose this would be to look in View->Other Windows->VisualGDB Diagnostics Console. All non-critical internal errors get logged there, so it might explain what is going on.
If nothing helps, please check that the Output file on the NMake Settings page of VS project properties (not VisualGDB project properties) points to the .vgdbsettings file.
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2306.msi
