[support]

Hi,

The .axf extension is used by the Keil compiler for the ELF files. VisualGDB follows the Linux naming convention for the built files, hence the ELF files it produces have no extension. I.e. you can find an equivalent of the AXF file for your project under the following path:<Project Directory>\VisualGDB\Debug\EmBGM13P22F512GA_Test01.

The .rsp files are used to pass the command lines of the tools, avoiding the Windows command line length limitation of 8192 characters. They do not contain any code or symbols on their own.

[support]

Sorry, it looks like you did not add “VERBOSE=1” to the GNU Make command-line arguments (see our previous reply), hence Make did not dump the gcc command lines.

Please try adding it as suggested and share the updated log that should include the exact gcc command lines used to build the code.

[support]

Hi,

Yes, simply use the Advanced Mbed Project Subsystem and you should be able to use the latest mbed version out-of-the-box.

[support]

Unfortunately, it’s hard to suggest anything specific without knowing the exact steps to reproduce the problem.

Please describe the steps required to reproduce it, starting from creating a new project (see this page) and we should be able to suggest what is going on.

[support]

Hi,

The easiest way to achieve this would be to use the CMake-based projects and add the following constructs to the CMakeLists.txt files:

if (CMAKE_BUILD_TYPE EQUAL "DEBUG")
set(CONFIG_SPECIFIC_MACROS CONTROL2)
endif()

and then simply add ${CONFIG_SPECIFIC_MACROS} to the regular list of preprocessor macros via VS Project Properties. This will affect both build and IntelliSense.

If it doesn’t work, please let us know and we will help you configure everything.

[support]

Strange. Please try enabling verbose build (add “-v” to Ninja command-line arguments or “VERBOSE=1” to GNU Make command line arguments via VisualGDB Project Properties -> CMake Proejct Settings -> Ninja/Make command) and then build the project again.

It will show the exact command lines used by the build system for each file. Please locate the command line for any file from that library and check what is going on (e.g. ${CMAKE_SYSROOT} got expanded incorrectly, or the path is not present in the command line at all).

If you are not sure, please post the corresponding command line from the build log and your updated target_include_directories() statement and we will help you understand it.

P.S. You can also try using our CMake Debugger to quickly understand what is going on. It allows stepping through CMake statements and will evaluate variables like ${CMAKE_SYSROOT}.

[support]

Hi,

No problem. The “Exclude the startup file from project” should exclude the startup_xxx.c file from the project (you can change it later via the first of page VisualGDB Project Properties, save the project and compare the .vcxproj and .props files against the versions checked in the sourec control to see what exactly the setting does).

The “Advanced Low-Level Driver Functions” sets the USE_FULL_LL_DRIVER preprocessor macro that in turn enables some advanced functionality in the STM32 SDK. You can search the STM32 low-level drivers for USE_FULL_LL_DRIVER to see what exact functionality gets affected by this setting.

If you are planning to stay up-to-date with the STM32 SDK, we advise NOT converting the project to a stand-alone one. Then simply updating the BSP via Tools->VisualGDB->Manage VisualGDB Packages will automatically affect all projects targeting STM32 devices. That said, you may need to apply minor edits to the projects; although the STM32 SDKs are usually backwards-compatible, sometimes small changes (e.g. adding new macros to the configuration headers) might be required.

[support]

Hi,

Sorry for the confusion. Although most of VisualGDB’s tutorials indeed show one project per solution, VisualGDB fully supports having multiple projects in the same solution.

Please simply right-click on the Solution item in Solution Explorer and select Add->New Project to add a new VisualGDB project (e.g. a unit test project) to the existing solution.

If it doesn’t work, please let us know and we will help you further.

[support]

Sorry, the settings in both cases look equivalent. To be fully sure, please consider reverting them back and forth 2-3 times and checking if the problem reoccurs consistently.

As a long-term workaround, please consider setting the GNUToolchainExtraPath MSBuild variable in the .vxcproj file. It is used internally by VisualGDB to propagate path directories exported by the selected toolchain, so you can edit it to inject the Python path into the environment as well.

Also, as the variable is lost between Visual Studio and MSBuild, it could be worthwhile verifying if the problem can be reproduced with the regular Exec task on a regular non-VisualGDB project and checking with the Visual Studio support whether it’s a bug that could be fixed on the VS side or if there is a setting controlling this behavior.

[support]

Sorry, not sure what exactly you meant. Please try describing the problem using the first 2 steps of the 3-step format shown here and we will suggest the best solution.

[support]

Sorry for the delay. Please feel free to send the log file to support@sysprogs.com.

Unfortunately the SIGUSR1 workaround will not work when using an IDE like VisualGDB because the following events will take place:

1. GDB will catch SIGUSR1 and report to VisualGDB that the session is stopped.
2. VisualGDB will issue the regular status querying commands (e.g. will query the backtrace and register contents).
3. GDB will immediately resume execution per your custom “catch” handler and will ignore the commands issued by VisualGDB.
4. VisualGDB will wait until the time-out specified in the settings and will then show the “GDB not responding” overlay.

We should be able to modify VisualGDB to selectively load the symbols as fast as the current setup (it will use the set stop-on-solib-events command and will then issue symbol load commands based on the library whitelist), however we would need to see that log in order to make sure we can make the new logic easily discoverable for all users.

[support]

Good to know it works.

Regarding the Arduino IDE, it looks like some sort of a conflict between different versions of the packages in the Arduino directory and the VisualGDB directory. We should be able to fix this if you could archive the entire Arduino IDE directory and also the C:\Users\Johanan\AppData\Local/Arduino15 directory so that we could reproduce everything on our side. But since the current workaround fixes the problem, you can simply proceed with having the Arduino IDE directory unspecified.

[support]

Thanks, this indeed helps understand what is going on.

Indeed, the ../../=/usr/local/include syntax is incorrect (the correct one should be ${CMAKE_SYSROOT}/usr/local/include). The development branch of VisualGDB 5.5 should already use the correct syntax, but if you don’t want to upgrade before v5.5 reaches the stable release stage, simply try replacing C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot with ${CMAKE_SYSROOT} and the project should build both on Linux and Windows.

[support]

Sorry, this looks like something inconsistent between the system codepage, git codepage and MinGW codepage. Given that the problem does not affect build and that non-latin characters in paths are not recommended due to conflicts with other tools (e.g. gdb), we will not be investigating this further, sorry.

[support]

This looks like some sort of incompatibility between a specific version of the toolchain and a specific version of OpenCV.

Unfortunately, as both components are outside of our control, we are not able to cover this with our regular technical support, so our best advice would be to try asking on the OpenCV forums if anyone has encountered similar errors before.

[Author]

Posts