Forum Replies Created
-
Posts
-
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.
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.
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.
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
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.
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.
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.
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.
Hi,
Sorry, unfortunately not much. As this kernel version was discontinued ~7 years ago, most modern tools will likely not support it anymore, so we would advise switching to a newer system that runs a 3.x or a 4.x kernel.
Hi,
Please try exporting your VS color settings via Tools -> Import and Export Settings and then restoring them if the VisualGDB installation resets them.
Hi,
Thanks for checking this. If the “print” command works, this is likely an issue between VisualGDB and gdb, so we should be able to fix it easily.
Please create a diagnostic gdb log showing the incorrect value obtained via the “watch” window and the correct value for the same variable obtained via the “print” command and we should be able to see what is going on.
Hi,
Sorry, we don’t support older kernels officially as they are missing many APIs required by various parts of VisualKernel (e.g. our Ethernet debugging driver and the fast module enumeration driver). As we provide source code for both of those components, you might be able to patch them to run under older kernels, but we won’t be officially supporting the 2.4 kernel as it is no longer actively maintained and not used in modern distros.
Hi,
If you are using the Segger GDB stub, yes, the stub is responsible for reading the ITM-related registers and generating the output stream shown in the Raw Terminal window, hence it’s up to the stub to control the exact output format. Please check with Segger whether there is an option for removing the that. Another option would be to create a basic tool that will work like a proxy server between the gdb stub and the raw terminal, removing the extra symbols (you would need to know where exactly the Segger stub inserts the channel number bytes).
Hi,
Thanks for pointing out the missing sram_layout for the vendor samples. Indeed it was only defined when using the HAL or StdPeriph framework that is used with regular projects, but not with lightweight STM32CubeMX samples. We will also fix this in the upcoming BSP update.
The RAMDTCM_BASE issue looks like a conflict between the sample-specific system file and the default linker script used by VisualGDB. We will retest this as a part of our BSP tests and will ensure that the correct linker script is used with the lightweight samples.
It’s great to hear that you are happy with VisualGDB. Let us know if you encounter any further issues, or have any suggestions and we will be happy to make VisualGDB even better.
OK, we have done some investigation on this. Although we were not able to locate the problem yet, we can walk you through pinpointing it. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2403.msi
First of all, please check that adding the header files to Solution Explorer adds their directories as COMPONENT_SRCDIRS to component.mk (although there are no source files in those directories, VisualGDB will use the COMPONENT_SRCDIRS statement to locate the headers).
If yes, please open View->Other Windows->VisualGDB Diagnostics Console and reopen the project. Check for diagnostic lines like “Will search for headers for <…> in <…>” and “Found <…> header files for <…>”. Do those lines make sense (i.e. do some paths look incorrect)?
If you are not sure, please let us know the full paths of the header directories, attach your component.mk and the entire diagnostic log.
