Forum Replies Created
-
Posts
-
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
Hi,
Yes, we should be able to add an option to replace the raw addresses with $bp or $sp-relative addresses or “section name + offset” syntax (or add another column for that).
With symbols, VisualGDB can already highlight them (and also stack frames) via the “show global symbol locations” button. If it isn’t helpful in your scenario, please let us know the details so we could take it into account when designing this update.
Hi,
The External Memories page of VisualGDB Project Properties is essentially a convenient graphical way of editing the linker scripts and defining the macros for assigning individual variables to sections. So if you are not using the Custom edition, you can achieve the same functionality by editing the files manually (we can also show the necessary modifications to the XML files to make the custom memories appear in Embedded Memory Explorer). You can find extensive documentation on the GNU linker scripts here. Another source of information would be to look through the ST examples from STM32Cube that support external memories (e.g. QSPI).
That said, if you don’t want to manually handle the linker scripts and prefer a convenient GUI that will handle the necessary edits for you, upgrading to the Custom edition might be worthwhile. You could use this page to get an automatic upgrade quote.
Hi,
This is likely caused by the differences between the way J-Link is integrated in different IDEs. Older IDEs like Keil implement most of the debugging stack from scratch and only utilize low-level functions (like reading a specific memory location) from the J-Link DLL.
VisualGDB is built on top of the gdb debugger (that maps high-level requests like “get a value of a variable” into lower-level requests) that requires an extra component (Segger GDB stub) provided by Segger. Since we don’t have access to the source code of that component, unfortunately we are not able to diagnose issues that happen inside it, although it should be covered by the regular Segger support.
Another option would be to try using OpenOCD instead of the Segger GDB stub (you can switch it via VisualGDB Project Properties). OpenOCD is less polished than the Segger gdb stub, especially when it comes to supporting non-mainstream devices, however there are no memory leaks in it that we are aware of.
Hope this explains. Let us know if you have any further questions.
Hi,
This looks like a memory leak in the Segger GDB stub. If you are using VisualGDB with J-Trace, this is a known issue that was recently fixed by Segger in their development branch and should be soon available as a public hotfix. Please double-check with their support regarding specific plans for this.
Hi,
This is likely caused by VisualGDB updating its cache. Although normally VS should not hang for 15 seconds – instead it should display a detailed progress message.
Either way, please try opening the View->Clang IntelliSense Diagnostics Console window. It will contain detailed output explaining what exactly the Clang engine is doing. Feel free to post some snippets from it and we can explain what exactly is going on behind the scenes.
Hi,
Some of the previous BSP releases from us contained a bug when selecting “softdevice programmed separately” caused the code to be compiled without softdevice support (i.e. excluding some functions and ultimately making the firmware unusable). The behavior you are describing might be caused by this bug.
If the file produced by the Nordic build scripts is much smaller, please check the memory utilization via View->Embedded Memory Explorer. It should help quickly locate the functions responsible for most of the RAM/FLASH footprint. If most of the footprint comes from the standard library, please ensure you are using newlib-nano and our latest GCC toolchain.
Hi,
According to our records, your 30-day trial has expired. In order to keep receiving technical support, please purchase a license.
