[support]

Hi,

The easiest way to do that would be to use the Quick Debug feature. Alternatively you can add the ‘VisualGDB’ platform to an existing project via VS Configuration Manager and manually set properties like ‘Toolchain’ and ‘VisualGDB Settings’ file via VS project properties. You can copy the .vgdbsettings file from an existing VisualGDB project as well as the other settings.

[support]

Hi,

The “Error: JTAG scan chain interrogation failed” error usually indicates wiring problems. Please double-check your connections. If this does not help, please try using exactly the same hardware and layout as shown in one of our tutorials.

[support]

Hi,

Sorry, the screenshot did not get pasted properly. Could you try uploading it to imgur or any other image hosting?

[support]

Hi,

We have double-checked the sources of CppUTest and the solution is actually much simpler.

Please comment the ‘return’ line after the following line in SysprogsTestHooks.cpp:

fprintf(stderr, "SYSPROGS_TEST_REPORTING_PIPE not set. Cannot report test status!\n");

This will let the tests proceed even when the VisualGDB-specific reporting mechanism is not set, so you won’t need any special command line.

[support]

Hi,

SysTick handler should be handled normally. Perhaps some sort of memory corruption is taking place? Do you see the SysTick listed in the live profiling window? Does temporarily disabling interrupts get it over the place where it usually gets corrupt?

Regarding “check all” and “uncheck all”, we have added those buttons in our development branch and will include them in the next maintenance build.

[support]

Hi,

Thanks for the update log. Now it looks like VisualGDB is getting the expression type correctly, but it looks like there are too many expressions checked in one session, so it’s hard to understand what is broken.

Please try creating a local variable of the list type, clear the GDB Session window and add that variable to watch. Then please attach a screenshot of the watch window and the corresponding gdb log. Please avoid evaluating that variable before you reset the log, as VisualGDB will then cache its type and not re-query it, so we will not be able to see what is going on.

[support]

Hi,

Looks like you are using the toolchain designed for barebone embedded devices on a Linux-based board.

Please try using one of the Linux-based toolchains (e.g. Raspberry Pi).

[support]

Hi,

Thanks, we have managed to reproduce this and it simply looks like the FLASH erase takes longer than the default timeout of 5 seconds.

Increasing the timeout to 10 seconds solved the problem in our setup. We will update the default timeout in the next toolchain release. As a workaround, please increase it manually by adding the following element to your .vgdbsettings file inside the DebugMethodProperties/Entries element:

        <KeyValue>
          <Key>com.sysprogs.esp32.openocd.alg_timeout</Key>
          <Value>10000</Value>
        </KeyValue>

[support]

Hi,

Thanks for the log, however it does not include the -var-create command that is essential to understanding why VisualGDB does not treat this variable as a list.

The output should normally look like this:

-var-create --frame 0 --thread 1 - * "l"
^done,name="var1",numchild="1",value="{...}",type="std::__cxx11::list<int, std::allocator<int> >",thread-id="1",has_more="0"
ptype/mt std::__cxx11::list<int, std::allocator<int> >
&"ptype/mt std::__cxx11::list<int, std::allocator<int> >\n"
type = class std::__cxx11::list<int, std::allocator<int> > [with _Tp = int, _Alloc = std::allocator<int>] : protected std::__cxx11::_List_base<_Tp, _Alloc> {
}
OK
-var-info-path-expression "var1"
^done,path_expr="l"
-data-evaluate-expression --frame 0 --thread 1 "\(void\ \*\)&\(\(l\)\._M_impl\._M_node\)"
^done,value="0x7fffffffea10"

Please also ensure you are using the latest VisualGDB 5.2 as the STL container visualization was significantly optimized in this version.

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

[Author]

Posts