[support]

Hi,

Our support for AVR devices is somewhat basic as they are much less popular than ARM-based devices like STM32.

VisualGDB actually relies on an open-source tool called AVaRICE in order to handle the low-level communications. According to this thread, AVaRICE should be able to support Atmel ICE, although we have not tested it explicitly and cannot guarantee it. We would recommend experimenting with the AVaRICE command line to see if it gets to work.

If you encounter any problems, feel free to post the details here and we will try to help, but unfortunately we cannot give a 100% guarantee that Atmel ICE will work.

[support]

Hi,

Looks like your toolchain might be corrupt. Please try locating the libstdc++.so file mentioned in the error message and check its contents. If it looks like a text file containing the path to another file, it could be an incorrectly unpacked symlink. In this case please try copying the target file over that libstdc++.so file.

[support]

Hi,

This could happen if the file is not explicitly included in your VC++ project. Could you double-check that it’s explicitly there? If not, would you be able to reproduce the problem on a basic “hello, world” application and send it to us so that we could investigate this further?

[support]

Hi,

The SSH host aliases are available starting from the Custom edition (see the feature matrix). If you are using a lower edition, you can achieve the same effect by defining Windows environment variables (e.g. DEPLOYHOST=linuxbox) and manually editing the .vgdbsettings files to use those environment variables (e.g. replace linuxbox with $(DEPLOYHOST)). Note that you will need to restart Visual Studio after you update the Windows environment variables.

[support]

Hi,

Sorry, this is sort of a rare case, so we won’t be supporting this out-of-the-box. BTW, for new projects we recommend using MSBuild. It actually works very fast (when building both on Windows and Linux) and is much better integrated with VS (VisualGDB has 100% reliable access to all build settings and does not have to guess them).

[support]

Hi,

Sorry, not fully sure we got you correctly. In the previous post you mentioned the following instruction:

0x000001f0  strb r7, [r0, r2]

But in your last post the instruction at that address looks different:

0x1f0 <SystemInit>:    push    {r7, lr}

Could you please double-check what is the actual instruction programmed at address 0x1f0 in the FLASH (if you run “x/10i” before connecting to the target, gdb will read the code from the ELF file and not from the actual FLASH memory)?

[support]

Hi,

This could happen if you switched the language standard in the Makefile manually and did not let VisualGDB retest the settings so that it could query the correct __cplusplus version from your gcc. If you are not sure, please let us know if you are using MSBuild or Make and how exactly you changed the project to C++11.

[support]

Hi,

This depends whether you are using MSBuild, GNU Make or CMake. For MSBuild you can achieve this via VS Project Properties, for other build systems you would need to manually edit the configuration files (e.g. Makefile) and explicitly specify the debugged executable via VisualGDB Project Properties as automatic detection won’t work anymore.

[support]

Hi,

You can achieve the same effect by manually adding the source files and preprocessor macros listed in the framework definition. E.g. for the ‘fixed stack/heap’ they are defined in the BSP.XML file as follows:

      <AdditionalSourceFiles>
        <string>$$SYS:BSP_ROOT$$/StackAndHeap/StackAndHeap.c</string>
      </AdditionalSourceFiles>
      <AdditionalPreprocessorMacros>
        <string>FIXED_STACK_SIZE=$$com.sysprogs.bspoptions.stackheap.stacksize$$</string>
        <string>FIXED_HEAP_SIZE=$$com.sysprogs.bspoptions.stackheap.heapsize$$</string>
      </AdditionalPreprocessorMacros>

If you are not sure, let us know and we will provide more detailed steps.

• This reply was modified 8 years, 2 months ago by support.

[support]

Hi,

Could be an antivirus bug or a corrupt filesystem. If you encounter this problem again, feel free to let us know and we will help you resolve it.

[support]

Hi,

This could happen if the property used to store the location of the .vgdbsettings file was set incorrectly. Please try holding Shift while right-clicking on the project and VisualGDB will display the corresponding menu item even if it cannot confirm that it’s a valid VisualGDB Project. It may then display an error that will help locate the root cause for this.

If it does not help, please let us know if it’s an MSBuild-based project or not and we will suggest further diagnostic steps.

[support]

We are aware of this and are gradually switching our GUI to the newer WPF framework that handles high resolution better. We have also received feedback that the old WinForms-based GUI scales better after installing Windows 10 Creator Update.

[support]

Hi,

Sorry, not fully sure we understood you correctly. Do you mean that some of the VisualGDB GUI does not display Chinese characters correctly or that VisualGDB is not translated to Chinese?

[support]

No worries. Let us know if you encounter further problems and we will be happy to help.

[support]

Hi,

Unoptimized debug builds are expected to result in much slower execution time; this is by design. This is needed because the optimizer would try to place as many variables as possible into registers and will reuse the same register for a different variable once the old one is no longer needed, making it only possible to evaluate its value while it is still needed by other code. Other optimizations would make stepping less intuitive by combining reusable code fragments like the code for the ‘return’ statements. Our best advice would be to play around with the optimization setting, changing it between -O0, -Og-, -O1, -O2 and -O3. Increasing optimization will increase the speed, but make the debugging experience harder.

Regarding unstable code, most likely your code either contains a bug that corrupts memory (but is not reproduced without optimization) or relies on some assumption that does not hold with full optimization. E.g. the following code may hang in the release build because the optimizer will try to move reading of ‘done’ outside of the loop:

int done;

void InterruptHandler()
{
    done = 1;
}

int main()
{
    //...
    while (!done)
    {
    }
    
    printf("done\n");    
}

Declaring the ‘done’ variable with the ‘volatile’ keyword will solve the problem.

[Author]

Posts