Forum Replies Created
-
AuthorPosts
-
support
KeymasterGood to know it works. The new suggestion GUI relies on the new and somewhat underdocumented APIs from Visual Studio, so it may indeed have unexpected side effects that were not found by our internal tests. We will definitely appreciate any feedback on it and will be happy to fix any issues that we can reproduce.
Edit: we just caught an issue that was sometimes causing the “waiting for the editor operation to complete” window to appear. We have fixed it in this build: VisualGDB-5.6.1.4150.msi.
-
This reply was modified 4 years, 3 months ago by
support.
support
KeymasterHi,
This is correct. The newer versions of OpenOCD, BSPs and other packages often rely on the new features introduced in the recent VisualGDB versions, and will not work with the older VisualGDB releases.
If you would like to stay up-to-date with the latest tools and packages, we recommend using the latest version of VisualGDB as well.
support
KeymasterHi,
Sorry about that. Please try this build: VisualGDB-5.6.1.4149.msi
support
KeymasterHi,
The Live Variables (renamed to Live Watch in v5.4) and other live functionality only works for targets that support reading the memory without stopping the CPU. This includes most new ARM devices and RISC-V devices, but not ESP32 or ESP8266.
support
KeymasterHi,
Thanks for reporting this. We have successfully reproduced the problem and fixed it in the following build: VisualGDB-5.6.1.4144.msi
If you encounter further issues, please feel free to let us know more details, and we will be happy resolve them.
support
KeymasterHi,
No problem. First of all, please note that this is outside our regular product support scope, as it is a general C/C++ programming question, rather than a VisualGDB-specific issue.
However, as we have helped you port the project from Keil to GCC via our consulting service, we will gladly explain this as a part of the porting support.
The __DATE__ macro is only expanded by the compiler when the corresponding source file is physically compiled. E.g., if none of the project files have changed since the last build, the project will be considered up-to-date, and the old binary with the old __DATE__ value will be preserved. This also works on the file level. E.g. if main.c contains a printf(__DATE__), or a similar statement, modifying auxiliary.c will build a newer firmware version, but it will still show the old date, because the function checking it was not rebuilt this time.
If you would like to ensure that the __DATE__ value is always up-to-date, please consider making a dedicated function that checks and returns it in one of the .c files (not headers that are used by multiple sources) and add a custom pre-build step that will reset the timestamp on that .c file (e.g. using the touch command from MinGW or any other similar tool).
You can also simply do a full rebuild (Build->Rebuild All). This will make sure all files are rebuilt, so the old date will not be cached anywhere.
support
KeymasterNo problem. We were delaying the update to Ninja 1.10, as it caused issues with NRFConnect projects. However, the latest NRFConnect release has solved them. Please try this build: VisualGDB-5.6.1.4142.msi
We will also include the latest Ninja version in the upcoming VisualGDB 5.6 Beta 2.
support
KeymasterHi,
The specific examples come from the device vendors (Nordic in this case). We do not test every example on every device and generally advise contacting the device vendor if some of the examples don’t work.
That said,the Nordic devices are somewhat trickier to debug than other device families, because their proprietary network hardware may stop working if the core it stopped in a debugger for too long. In our experience, using non-intrusive debugging techniques (e.g. Fast semihosting and Live Watch) works better than the regular step-by-step debugging.
Another issue is that the NRFConnect SDK normally sets the optimization level to -Og instead of -O0, making GDB somewhat less precise. VisualGDB can override the optimization level to -O0 via VisualGDB Project Properties -> NRFConnect Project -> Optimization = Disable Completely, however it will increase the amount of memory used by the application (heap/stack) and may cause runtime errors for some examples.
We would normally advise the following steps to troubleshoot it:
- Try completely disabling optimization. Do the breakpoints work correctly?
- If not, try adding a hardcoded breakpoint to the same location where you would normally set a regular one:
__asm("bkpt 255")
- If the hardcoded breakpoint doesn’t work, disabling optimization has triggered errors (e.g. heap/stack overflows in the project). You can then revert to the “optimize for debugging” setting and manually disable optimization for a select set of sources where you would like to have precise debugging. This can be done by editing CMakeLists.txt as shown below:
set_source_files_properties(src/main.c COMPILE_FLAGS -O0)
The SysprogsDebuggerAttached logic should work out-of-the-box. However, the Zephyr thread enumeration in NRFConnect SDK 1.5.1 requires the following hotfix: VisualGDB-5.6.1.4142.msi
support
KeymasterHi,
This looks like the .vgdbcmake and CMakeLists.txt files got out-of-sync. Please try creating a new project for the same device from scratch and check if it works. If it does, please try comparing the .vgdbcmake and CMakeLists.txt files between the 2 projects and adjusting the broken project until it matches the one that loads successfully.
support
KeymasterHi,
No problem. Please follow the instructions on the following page to fix this: https://visualgdb.com/support/loadfail/
support
KeymasterHi,
No problem, please try this build: VisualGDB-5.6.1.4141.msi
VisualGDB will now correctly remember the manually specified register file for STM32CubeMX-based projects.
support
KeymasterThanks, we have reproduced the issue and updated VisualGDB to handle the -include switches reported by the new CMake correctly.
Please try this build: VisualGDB-5.6.1.4132.msi
June 2, 2021 at 12:41 in reply to: VisualGDB broken after updating VS 2019 from version 16.9 to 16.10 #30626support
KeymasterNo problem. You can always purchase multiple years of maintenance in advance if you believe you will need it for your project. Simply use the renewal button multiple times any time after purchasing the license, and each renewal will add 1 year to the expiration date. You can also contact our sales to get a quote if you need it billed as a single maintenance package.
June 2, 2021 at 11:39 in reply to: VisualGDB broken after updating VS 2019 from version 16.9 to 16.10 #30624support
KeymasterVisualGDB 5.4 was released over 2 years ago and is no longer maintained. If you would like to take advantage of the latest features, updates and hotfixes, please consider renewing your license here: https://sysprogs.com/splm/mykey
June 2, 2021 at 11:31 in reply to: VisualGDB broken after updating VS 2019 from version 16.9 to 16.10 #30621support
KeymasterHi,
This a known issue caused by a change in VS 16.10 that breaks backward compatibility. We have released hotfixes for the active VisualGDB versions (5.5 and 5.6) on the day it was reported.
Please see the following thread for details: https://sysprogs.com/w/forums/topic/unable-to-use-clang-intellisense-after-upgrading-vs/
-
This reply was modified 4 years, 3 months ago by
-
AuthorPosts