[support]

Hi,

If you are running Jenkins on Linux, you would need to use the unmodified version of CppUTest. The exact steps to use it are different on different Linux distros, so searching online for <your Linux distro> cpputest should normally get relevant instructions.

If this helps, we could also add a command-line switch that will disable VisualGDB-specific test reporting so that you could run your tests on Linux by adding something like “-standalone” to the command line. Let us know if you would prefer this.

[support]

Hi,

Looks like you are trying to view a dump related to a shared library. In that case you would need some extra steps to ensure the symbols are read properly:

1. Copy the main executable that corresponds to the dump on your Windows machine and specify it in the Quick Debug settings instead of the .so file.
2. Copy the .so file with symbols and any other relevant .so files to a directory on the Windows machine (e.g. c:\symbols) and run “set solib-search-path c:/symbols” via the ‘enter additional startup commands’ option so that GDB can locate the libraries.

You can check that the symbols for .so files have been loaded by running the “info shared” command via the GDB Session window. If they are not loaded, please double-check the listed libraries, symbol files and the search path.

The “cannot read memory” error is not related to symbol handling. Most likely gdb tries to some heuristics while unwinding the stack (or Visual Studio tries to follow a pointer) and reaches an area of memory that is not included in the dump file. This is normal and should not interfere with the rest of the functionality.

[support]

Hi,

The errors shown in the OpenOCD log you attached should not interfere with programming.

Most likely your board is slightly different from the regular nRF52 boards and the code needs to be adjusted somehow. We would recommend first trying it with the nRF52-DK board as we have explicitly tested VisualGDB-generated projects with it. Once you get it to work, you can try checking your board manufacturer’s website for instructions on configuring projects for that board and perhaps board-specific examples.

[support]

Hi,

When you are importing 3rd-party projects, VisualGDB indeed cannot automatically guess the include directories and preprocessor macros used for building the project as they are stored in different formats for different project types.

We would recommend simply importing the project via the import wizard and then using the automatic header directory discovery to quickly fix the missing include directories.

You can get a quick overview of the import process in this tutorial: http://visualgdb.com/tutorials/arm/stm32/cube/

Please note that if you are importing a Keil project, you would need to replace the assembly files (.S) with the ones compatible with GCC. STM32 examples usually contain them in a separate subfolder.

If the project still does not build after following these steps, please share the error messages you get and we will suggest how to resolve them.

[support]

Hi,

The “instrumented stack stream corrupt” error is shown when the stack frames reported by the instrumented program are inconsistent. This could happen if you are using an unsupported RTOS or are manually switching thread contexts.

It is hard to say what exactly is causing this based on just the description, so we would recommend the following steps to pinpoint it:

1. Identify roughly where the problem happens (e.g. after some action is started)
2. Set a breakpoint just before that action.
3. Clear the live profiling view
4. Resume the program
5. Once the problem happens, use the stacks displayed in Live Profiling to understand the last function call that was captured successfully. Then try to set a breakpoint there and step through it trying to reproduce the problem.

[support]

Hi,

This message appears because VisualGDB uses a special mechanism to get structured output from the tests that can be properly displayed in Visual Studio. This involves creating a temporary pipe and setting an environment variable so that the application can find this pipe.

If you want to run VisualGDB unit tests from Jenkins, we would recommend running the VisualGDB executable with the /runtests argument as shown at the end of this tutorial. This will automatically configure everything and save the output in an XML file.

If you want to run your tests without VisualGDB, you would need to manually modify the project to build with the regular CPPUTest instead of the version that comes with VisualGDB.

[support]

Hi,

You can do that with the latest VisualGDB 5.2, but you would need a cross-gdb for that (you can use one of the versions shipped with our toolchains). Simply check the “Use a cross-compiler on the Windows machine” checkbox and specify the path to your gdb executable.

[support]

Hi,

The Qt Designer does not generate the ui_MainWindow.h file. The file should be generated on the Linux machine during compilation and then downloaded back to the Windows side by VisualGDB.

Can you confirm that the ui_MainWindow.h on the Linux machine is still not regenerated?

[support]

Hi,

This looks like a bug. Could you let us know where do you edit that custom action? Is it a part of the custom pre-build/pre-debug actions or something else?

[support]

Hi,

You can do it via VisualGDB Project Properties -> Debug Settings -> Program Arguments.

[support]

Hi,

This is by design. Each command is started in a separate SSH channel, so the previous commands won’t affect the next ones. This is by design as otherwise unforeseen side effects from some commands executed early could cause very hard-to-diagnose bugs later.

[support]

Hi,

Sorry about that. The STM32 code indeed changes over time and while we automatically test the samples included with VisualGDB, the code in the tutorials and on the forum is not updated that frequently.

We have fixed the gears.cpp file, so you can download the newer version via the old link or simply add “#include <vector>” to the beginning of the file.

Please note that you will also need to enable the “provide default stubs for system calls” in VisualGDB Project Properties and follow the instructions in the tutorial to add the gear icon as a resource.

[support]

Hi,

The link you mentioned is the correct one. Perhaps the download was corrupt? Please let us know which VisualGDB version you are using and attach a screenshot of the toolchain selection page so that we could help you understand what’s wrong.

[support]

Hi,

Thanks for the detailed reply, this explains where the problem happens.

Looks like the code responsible for erasing the FLASH memory does not work properly. Could you confirm that he same happens with a basic “LEDBlink” application that is artificially made larger by adding code like this:

const char __attribute((section(".rodata"))) bigblock[1024 * 1024] = { 1, };
    
void app_main()
{
    volatile int x = bigblock[0];
}

[support]

Hi,

Sorry about the confusion. The tutorial mentions that Olimex ARM-USB-OCD-H is not supported by the Xtens JTAG software that is deprecated in favor of OpenOCD. If you are using OpenOCD (see the link from the original tutorial), you can use it. We have explicitly tested it with ARM-USB-OCD-H and have feedback from other users that the Tiny version works as well.

Hence we would recommend using ARM-USB-OCD-H, although the Tiny version is most likely OK as well.

[Author]

Posts