[support]

Hi,

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]

Hi,

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]

No 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]

Hi,

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:

1. Try completely disabling optimization. Do the breakpoints work correctly?
2. If not, try adding a hardcoded breakpoint to the same location where you would normally set a regular one:

   __asm("bkpt 255")

3. 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]

Hi,

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]

Hi,

No problem. Please follow the instructions on the following page to fix this: https://visualgdb.com/support/loadfail/

[support]

Hi,

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]

Thanks, 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

[support]

No 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.

[support]

VisualGDB 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

[support]

Hi,

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/

[support]

Hi,

Please refer to this page for a detailed overview of the Clang IntelliSense settings, and project types where it can be turned off.

[support]

Hi,

No problem, we have reproduced and fixed the issue with the component list. Please try updating to the latest CMake package via VisualGDB Package Manager.

We could not reproduce the issue with the headers though. Please try closing the solution, deleting the build and .visualgdb folders and reopening it again. If it doesn’t solve the problem, please try following the steps below to track it down:

1. Take a note of the specific source file that reports missing headers and a specific header file that is missing.
2. Locate the target containing that source file.
3. Locate the <project directory>\build\VisualGDB\Debug\.cmake\api\v1\reply\target-<ID>.json file corresponding to that target and make a backup of it.
4. Install the old CMake version manually. You can simply rename the file to .tgz and extract it to %LOCALAPPDATA%\VisualGDB\CMake.
5. Reload the project and confirm that the problem no longer occurs.
6. Locate the updated json file for the target.
7. Attach both json files (please put them into a .zip archive) and let us know the exact source file that triggers the error, the exact header file that is missing, and the directory where that header file is located when it’s found (when using the old CMake build). This should help us track it down and release a hotfix.

 

[support]

Thanks, it looks like the project file is using a slightly different way of specifying the linker script, that breaks our project importer.

Please try this build: VisualGDB-5.6.1.4131.msi

[support]

Hi,

Please see the following forum thread for more details: https://sysprogs.com/w/forums/topic/com-port-window-font-raw-terminal/

[Author]

Posts