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

[support]

Sorry, it’s hard to suggest anything specific without knowing more details (how exactly is the target declared, what is the current directory with the header file and exactly is is spelled in the Makefile, what exactly gets edited in the CMakeLists.txt file).

One possible cause for this would be CMakeLists.txt using the regular /path/on/target syntax to specify include directories instead of ${CMAKE_SYSROOT}/path/on/target. The former syntax will only work when compiling directly, while the latter will work both when building on Linux and Windows.

VS properties for the target can be opened by right-clicking on the target (specific executable or library) in Solution Explorer and selecting “Properties”.

Edit: the VisualGDB 5.5 development branch does automatically use the ${CMAKE_SYSROOT} syntax for automatically discovered directories (e.g. VisualGDB-5.5.1.3300.msi), however it hasn’t fully passed all our internal tests and may be less reliable than the stable v5.4 release.

• This reply was modified 5 years, 9 months ago by support.

[support]

Thanks, looks like this memory layout slightly changed the format of the output from objdump that was used by VisualGDB to gather disassembly data.

We have fixed it in the following build: VisualGDB-5.5.1.3299.msi

[support]

Sorry, this might be something set on the VS level. Please try running notepad.exe instead of the batch file (so that the build waits until you close Notepad).

Then use the  Process Explorer to check the environment block of the Visual Studio itself (devenv.exe), launched Notepad instance and the MSBuild executables (msbuild.exe) if you are using MSBuild.

Let us know at which stage is the PATH reset and we might be able to suggest a workaround.

[support]

Thanks, it looks like the new STM32 Arduino package builds executables without debug information by default.

We have updated VisualGDB to automatically detect and fix this condition: VisualGDB-5.5.1.3298.msi (see the bar on top of the source files belonging to the Arduino project).

[support]

Hi,

Sorry, no news for STM8.  STM32WB is already supported (see the following tutorials: https://visualgdb.com/w/tutorials/tag/stm32wb/).

[support]

No problem, it turned out our OpenOCD toolchain was using the old-style definition file that had hardcoded paths. We have updated both the toolchain and the OpenOCD repository so that they don’t have any paths hardcoded and will work out-of-the-box with arbitrary locations.

We have also fixed the “Debugging exited without any breakpoint hits”  error (there was a glitch in one of the CMakeLists files, although it’s hard to say why it didn’t trigger with the old path/toolchain).

Let us know if you find the root cause of the serial number matching problem and we will be happy to update our OpenOCD package.

[Author]

Posts