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

[support]

Hi,

We have never tested OpenOCD with any of those, so their support may be outdated or they may not be compatible with ESP8266. We would recommend trying it with Olimex ARM-USB-OCD-H; it is fairly inexpensive and works very well.

[support]

Hi,

Please try downloading the repackaged TI toolchain from http://gnutoolchains.com/msp430/

It contains support for many new devices including MSP430FR6989.

[support]

Hi,

Sorry, this looks like something too specific and very error-prone, so we won’t add any special GUI for that. You can easily do it though by clicking “copy linker script” on the Makefile Settings (or MSBuild Settings) page of VisualGDB Project Properties and editing the copied file via Visual Studio.

[support]

Hi,

OK, then please try modifying the .ui file and build the project. Do you see the “uic’ing <file name>” line? If not, please post the full paths to the .pro file and the .ui file here along with your FORMS = … line from the .pro file so that we could double-check those.

[Author]

Posts