Forum Replies Created
-
Posts
-
Good to know it works. We have also double-checked the download file extension and it appears correct. If you encounter the issue again, please let us know the repro steps and we will investigate.
Hi,
This looks like VisualGDB incorrectly reformats the value obtained from gdb. If you could share a full gdb log and a log from View->Other Windows->VisualGDB Diagnostics Console, we should be able to find the root cause and release a hotfix promptly.
Hi,
Looks like you don’t have sh.exe in your PATH variable. Please try adding the directory containing it (would normally be bundled with your Git installation) to PATH, or edit the run-sh.bat file inside the OpenOCD repository to specify the path manually.
We have also updated our OpenOCD repository to show a more meaningful message when sh.exe is missing.
Hi,
Please follow this tutorial to diagnose common library-related problems.
Hi,
Currently we are still researching the ways to reduce the RAM use by the profiling counters. We should be able to get an ETA for this feature around the middle of the next week.
Thanks @jensa for confirming that it works for you.
@jose-cazarin, if it still doesn’t work with your setup, could you please share your project type (MSBuild/Make), the build configuration (build on target, or using a cross-toolchain) and share the code that triggers the problem so that we could recheck it on our side?
No problem, we have added a per-memory setting that controls the generation of the .bin files.
Please try this build: VisualGDB-5.5.2.3384.msi
Hi,
VisualGDB 5.5 Preview 1 could indeed show the VisualGDB Build window for non-VisualGDB builds. We have already fixed it in our development branch (you can try this build: VisualGDB-5.5.2.3372.msi).
The GDB Session window should only appear for VisualGDB-based debug sessions. If not, please try closing it manually and describe the exact steps to reproduce the issue from opening Visual Studio to triggering the problem. We are asking for this because the behavior is likely caused by some rare combination of settings or actions and we are not able to guess it, or suggest anything meaningful without knowing what exactly you are doing to trigger the problem.
Sorry, FreeBSD is much less popular than Linux, so ensuring full out-of-the-box compatibility with it has a lower priority for us.
It also looks like the problem is caused by the use of the 32-bit FreeBSD instead of a 64-bit one. Please consider switching to a 64-bit FreeBSD build instead.
As a quick-and-dirty workaround to make it work with a 32-bit FreBSD, please try locating the following line in SysprogsSync.cpp:
1#if defined(__FreeBSD__) && defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS == 64Then replace it with just
1#if defined(__FreeBSD__)This will break synchronization for files larger than 4 GB, however should work for all other cases.
Hi,
We have tested SysprogsSync with gcc versions as old as 4.2.1 (FreeBSD 9.2) and most modern Linux distros, however it looks like FreeBSD 11.1 is different from the environments we checked.
Normally, VisualGDB would automatically rebuild SysprogsSync with the USE_REGEX_H macro (avoiding the unsupported C++ regex API), however it looks like there are other issues preventing it from building.
Generally, the easiest way to get it working would be to disable SysprogsSync for that host via Tools->VisualGDB->SSH Host Manager->Host-wide Settings->SysprogsSync Engine = disabled. VisualGDB will then fall back to slower command line-based method of synchronizing files.
If you would like to get the maximum performance out of file transfers, please try modifying the SysprogsSync.cpp file as follows:
- Unconditionally define USE_REGEX_H
- Define PATH_MAX to be 1024
- Check your system headers for the correct way of including the stat64 support. SysprogsSync needs it to synchronize files larger than 4GB. Update SysprogsSync.cpp accordingly.
Once you can confirm that SysprogsSync builds successfully, please try renaming the built executable to SysprogsSync-v1.1 and placing it anywhere in the PATH on the target machine. Then restart Visual Studio and VisualGDB will automatically recognize it and will use it for high-speed file synchronization.
Yes, due to the way the settings are cached inside MSBuild, changing this indeed requires restarting VS, or reopening the solution.
Hi,
Normally, STM32CubeMX should specify the correct include directories in the .gpdsc file, and VisualGDB should pick them up.
However, in practice, the ST’s tool often drops include paths or writes invalid file paths in the gpdsc file, so random problems do happen.
If you could attach your gpdsc file, we might be able to add a workaround to our STM32CubeMX importer plugin to add the missing include paths. Alternatively, you can try patching the plugin on your side – we provide source code for most of the plugins interacting with external tools so that our users could tweak them to their needs.
Good to know it works. Feel free to reach out to us again if you encounter further issues.
Hi,
No problem, this is already supported. Simply use the “configure” button in the new output window’s toolbar to open the Advanced Output Settings where you can switch between the regular output window, advanced output window, and fine-tune other output-related parameters.
-
This reply was modified 6 days, 5 hours ago by
support.
Hi,
The JTAG-based FLASHing is done by the OpenOCD tool, so it would be possible to launch it manually and issue the FLASHing commands manually as well.
You can find out the command line used by VisualGDB to launch OpenOCD in the Debug->Windows->GDB Stub window and then use the GDB Session window (switch it to “All Output” and search for command starting with “mon” to see the commands sent by VisualGDB to OpenOCD to program the FLASH memory).
If you don’t want to setup the command lines and FLASHing commands manually, please try using the Debug->Program FLASH Memory command in Visual Studio that will automatically launch the necessary tools, program the memory and then disconnect the debug session.
