[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/

[support]

Hi,

Most likely, you are trying to import a project generated with an older version of  the STM32CubeIDE that specifies some settings differently. The easiest way to get it working would be to compare its .cproject file against one of the .cproject files that get imported successfully (e.g. from the STM32 SDKs), specifically looking for the com.st.stm32cube.ide.mcu.gnu.managedbuild.tool.c.linker.option.script option.

If it doesn’t help, please feel free to attach the .cproject file (please place it into a .zip archive if you would like to attach it here) and we will recheck why the STM32IDE importing plugin doesn’t work with it.

[support]

Thanks for renewing your support. Instrumenting the code for profiling could result in crashes if the original code was corrupting the memory, had possible race conditions or other implicit dependencies.

In order to troubleshoot it, please try the following:

1. Instead of using the Analyze command, try enabling real-time watch in VisualGDB Project Properties -> Dynamic Analysis, but don’t create any watches yet. Does this result in a crash?
2. If yes, please try changing the instrumentation settings on the Dynamic Analysis page to only instrument one or two functions (e.g. the one controlling the LED). Does the code still crash?
3. If instrumenting only one function stops the crashing, the problem is caused by instrumenting some of the low-level system functions. Please try excluding all low-level functions from being instrumented to see if it solves the problem.
4. If instrumenting only one function still causes crashing, please try reproducing the problem on a clean project created from scratch for the same device. Once you get it reproduced, please share the repro project with us and we will investigate it further.

[support]

Hi,

We normally advise using our CMake fork when building projects on the Windows side, as we routinely test various VisualGDB features with it. That said, you can configure VisualGDB to use a specific CMake executable via Tools->Options->VisualGDB->General->Tools->Full path to cmake.exe.

We have also updated our CMake fork based on the latest v3.20.3 release. You can update it via Tools->VisualGDB->Manage VisualGDB Packages.

[Author]

Posts