[support]

Hi,

Sorry for the delay. We have discovered an unrelated problem while investigating this, however it should not trigger for MSBuild-based projects.

We have rechecked the sample and applied the following workarounds:

• Manually defined sram_layout and VECT_TAB_SRAM (will be fixed in the upcoming BSP update)
• Replaced SCB_VTOR assignment as follows:

 SCB->VTOR = RAMDTCM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */

The sample did run correctly after those fixes. If it doesn’t work on your side, please attach an archive with your project (clean the project and remove the .vs folder before archiving) and we can compare it with the project on our side to see what could be causing this.

 

[support]

Hi,

Sorry about that, looks like a bug introduced by a recent refactoring. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2407.msi

[support]

Hi,

It looks like some sort of a communication issue between your Linux host and the Windows host.

Please ensure that you can ping the Windows host from the Linux host and that you can connect to port 139. If not, please double-check your firewall settings.

[support]

Hi,

Yes, if you already have a tool that connects to the Segger’s telnet port and accepts TCP connections on another port, simply add its invocation to VisualGDB Project Properties -> Custom Debug Steps and then configure raw terminal to open on localhost:<port used by the tool>.

Another option would be to modify the tool to print decoded output to stdout and simply use Custom Debug Steps -> Remote Console -> Use the following command.

[support]

Hi,

Our newlib-nano build (gcc-arm-none-eabi-6-2017-q2-update) is configured with the following flags:

../newlib/configure --target=arm-eabi --prefix=/q/gnu/newlib-nano/newlib-nano-install --disable-newlib-supplied-syscalls --enable-newlib-reent-small --disable-newlib-fvwrite-in-streamio --disable-newlib-fseek-optimization --disable-newlib-wide-orient --enable-newlib-nano-malloc --disable-newlib-unbuf-stream-opt --enable-lite-exit --enable-newlib-global-atexit --disable-nls --enable-newlib-nano-formatted-io

The configuration process creates many header files with generated flags, so it’s hard to give a definitive answer. If you would like to look deeper into it, please consider building it from sources on your side and verify which version of the code is built by injecting #error directives into the source files.

Another (easier) option would be to try setting breakpoints in other functions that should be called (see the call stack below) until you pinpoint the one that is not called:

> _read() C++ (gdb)
 _read_r() C++ (gdb)
 __sread() C++ (gdb)
 __srefill_r() C++ (gdb)
 __svfscanf_r() C++ (gdb)
 scanf() C++ (gdb)

Here’s the program we tested it with:

extern "C" int _read()
{
 asm("bkpt 255");
}

int main(void)
{
 int x;
 scanf("%x", &x);
}

[support]

Hi,

Thanks for the component.mk file. Please also let us know the full path of a header file that is not shown and share the entire output from the VisualGDB Diagnostics Console.

[support]

Hi,

No worries. This is actually a known issue of gcc (e.g. see this discussion). Generally, though, we advise avoiding non-static inline functions, as they could cause hard-to-diagnose problems in large projects where multiple source files define different versions of an inline function with the same name.

E.g. if file1.cpp defines inline void memset32(void *, int, int numberOfWords) and file2.cpp defines inline void memset32(void *, int, int numberOfBytes), the debug build (with inlining disabled) may silently replace one of the implementations with another one, as both functions will get compiled as weak global symbols. Declaring inline functions as static limits them to the declaring translation unit, fully avoiding this issue and also resolving the problem you encountered.

[support]

Hi,

Sorry, we don’t have a specific import plugin for Infineon DAVE, however the regular import mode in the wizard should be a good starting point (you would still need to specify include directories/preprocessor macros manually).

The “redefinition of variables” error most likely happens because the imported project includes a copy of some system files (e.g. peripheral drivers or startup files) that are already included in the VisualGDB project. It could be solved by locating such files and ensuring that you only leave one copy of them (i.e. either remove the one from the imported project, or unreference the corresponding embedded framework via VisualGDB Project Properties). Feel free to post the exact error message here and we can give more specific advice.

[support]

Hi,

Unfortunately that’s a tough one to diagnose. It typically indicates some sort of incompatibility between the libusb library (used by OpenOCD) and your USB controller driver (or some filter driver, e.g. provided by USB virtualization software). As the issue is caused in an external component, and we won’t be able to reproduce it on our side (as it’s specific to a certain USB driver), it’s hard for us to suggest definitive steps for resolving it.

Our general advice would be to try it on a different machine with a different USB controller or to try reinstalling all USB-related drivers (e.g. ST-Link driver, USB controller driver). Another option would be to build our OpenOCD fork from sources (see this tutorial) and try stepping through the USB-related functions. If you are OK going through this process, we can help you find the relevant parts of the OpenOCD code and will include a patch for the issue in our OpenOCD fork we could pinpoint it based on your observations.

P.S. Please double-check that you are using the “USB devices”, not “debug methods” view in VisualGDB Debug Settings, so VisualGDB can check and install the missing drivers. If not, this could be as easy as a missing USB driver for ST-Link.

[support]

Hi,

Could it be that your implementation of _read() was not declared with extern “C” and hence would not replace the original one? We have done a quick test with newlib-nano and scanf() did call the redefined _read(). If nothing helps, please try checking if your version of _read() is actually compiled in (e.g. set a breakpoint in _read by function name and see whether it resolves to your function).

Regarding email notifications, unfortunately we had to disable it some email servers classified those notifications as spam and prevented the delivery of regular emails from our domain as well.

With C++, there are a few cases where it could be beneficial to embedded projects, (e.g. using RAII to avoid “forgot to call release() before return” errors, or using templates as a more IntelliSense- and debugger-friendly alternative to bulky plain C macros), although whether it pays off depends on the project size, style and many other factors. VisualGDB is designed to support both Plain C and C++ projects, so it should provide comfortable development experience for both languages.

[support]

Hi,

Thanks for narrowing it down. It looks like a combination of our language service and the debug engine was indeed causing a rather strange race condition inside the VS editor, that resulted in evaluating the incorrect expression.

We have changed the expression finding logic in a way that no longer triggers the problem in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2406.msi

[support]

Hi,

Yes, GoogleTest uses the <GroupName>_<TestName> syntax for internal test symbol names, so VisualGDB indeed gets confused when the test name itself contains an underscore.

You could work around this by patching the %LOCALAPPDATA%\VisualGDB\TestFrameworks\com.sysprogs.unittest.googletest\TestFramework.xml file as shown below:

<TestIDRegex>([^_]*)_(.*)</TestIDRegex>

However, this will break if the test group names contain underscores. So if it’s possible to avoid underscores in your group/test names, we would advise doing that instead.

[support]

Hi,

OK, please try isolating one specific case of broken IntelliSense (e.g. some variable or function is not found) and check if it’s still related to the mismatching __cplusplus definition, or something else (e.g. missing hardware/software FP macros). If you need more detailed instructions on this, please let us know a specific example of an IntelliSense error and we will help you narrow it down.

[support]

Hi,

Unfortunately it’s hard to pinpoint the source of this without seeing the call stack. Please try checking the test logs and VisualGDB Diagnostics Console for more detailed errors containing a stack trace.

[support]

Hi,

Please double-check that your source files have the .cpp, not .c extension. Even if one .c file included a header file with C++ constructs, it would result in a build error.

[Author]

Posts