Forum Replies Created
-
Posts
-
Hi,
Please refer to the following page for details: https://visualgdb.com/support/oldpackages/
No problem, we actually do have a tutorial explaining the roles of various files and a recommended .gitignore setup. Please feel free to look through it: https://visualgdb.com/tutorials/arm/multiuser/
Hi,
You can remove the link to the original project by removing the ImportedProject element from the embedded profile file (typically called mcu.xml, stm32.xml, etc. in the project directory).
This will permanently disable this warning.
Please carefully read the second part of our previous reply. It describes exactly what to do if the newly created project works.
No problem, we will walk you through pinpointing it.
First of all, please try creating a similar project (GNU Make, same toolchain/target) and check if the project properties window works for it. If not, please make sure you can create regular VC++ projects (i.e. have the VC++ components installed).
If the newly created project works, please try opening the VS Project Properties (not VisualGDB Project Properties) for the project and check the NMake Settings page. Does the page appear properly and list the .vgdbsettings file as the primary output? If you cannot find anything suspicious, please attach a screenshot of the NMake Settings page and also the entire VS window having the problematic configuration selected, so that we could check for common issues.
Thanks for renewing your license. It looks like the project has not been fully loaded.
Please try updating to VisualGDB 5.5 Preview 4 and let us know if the problem persists. If it does, please attach an updated stack trace and we will help you troubleshoot it.
Hi,
It looks like your technical support has expired. We would be happy to help you resolve this, however we would kindly ask you to renew your technical support here first: https://sysprogs.com/splm/mykey
Hi,
Please reach out to our sales support for up-to-date information on licensing terms and restrictions.
No problem, we have updated VisualGDB to apply the font to both controls. Please try this build: VisualGDB-5.5.4.3541.msi
Timestamps for terminal output sounds like a good idea. We have added it to our backlog and will try to include it in one of the next VisualGDB releases.
Sorry, there is no option to disable the tooltips in code completion popups. However we should be able to easily add it, if requested by a paid user with an active support period.
No problem. The External Dependencies are managed by Visual Studio itself and not by VisualGDB. Please refer to Visual Studio documentation for more details on them.
The Device-Specific files folder is reserved for files managed by VisualGDB that are added to the project based on the device descriptions shipped with VisualGDB. We do not advise editing them, as it may break your project.
If you are getting weird build errors, please try searching the nearby source files for the definition of missing symbols and understanding where exactly they are defined (make sure you understand the differences between C++ definitions and declarations). Adding random files to the project in attempt to fix the build errors will only cause more weird errors and break the project further.
Hi,
No problem, please try again. There was a temporary issue with our servers that has been resolved.
Thanks for the logs. It looks like the problem is somewhere between gdb and the Segger GDB stub.
The easiest way to work around it would be to disable memory programming via VisualGDB Project Properties -> Debug Settings and then run nrfjprog as a custom pre-debug action. This will affect both the regular debug sessions and the “Program without debugging” command.
If you would like to narrow down the true cause of the problem, please try running gdb and JLinkGDBServerCL manually from the command line, connect gdb to the J-Link server and try programming and verifying the memory (load and compare-sections commands). If you can reproduce the problem, please check with Segger support, it might be a bug on their side (or a missing setting related to FLASH memory protection).
Another troubleshooting technique would be to start a regular debug session and use the VisualGDB’s graphical memory verification tool (chip icon on the GDB Session window). It will show the exact differences between the ELF file and the device memory, possibly pointing to the root cause.
Hi,
The “Failed to program sections” error is shown when VisualGDB fails to verify the FLASH memory contents after programming. Please try clicking the “Show Details” button to view more details or simply disable memory verification via Tools->Options->VisualGDB->Embedded->Other->Verify Memory when Programming.
P.S. You can find a find a detailed and searchable list of all VisualGDB settings here: http://visualgdb.com/settings/
Hi,
The Nordic SDK is indeed one of the hardest ones to configure compared to other SDKs. Generally, it is configured by enabling features in the sdk_config.h file, including the related headers (and adding the corresponding include paths) and source files to the project.
To make configuration easier, VisualGDB maps most of the SDK’s features to the frameworks and configuration options on the Embedded Frameworks page. Enabling those features would add include directories and source files to the project. Also if you update to VisualGDB 5.5 Preview 4 and use the latest Nordic SDK, it will automatically suggest configuration changes for missing symbols and header files that could be discovered during our automated SDK releasing process.
Beyond that, please plan sufficient time to get accustomed to the new SDK. Although VisualGDB can automate most of the troubleshooting, getting the right configuration for a specific project type might still require some iterations. If you are new to the Nordic SDK, please consider selecting “Nordic SDK examples” on the Sample Selection page of the wizard, cloning a few samples similar to your setup and understanding the sources and headers that are involved in that functionality.
