Forum Replies Created
-
Posts
-
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:
#if defined(__FreeBSD__) && defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS == 64
Then replace it with just
#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.
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.
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.
Hi,
Sorry, code coverage is not supported for embedded projects yet. Obtaining the coverage for GCC-based projects requires a mechanism for transferring the coverage data from the target to the host, and there are a few caveats that make this task non-trivial. We are internally experimenting with it and will very likely support it in one of the next preview builds for v5.5. However, as of today, the only way to obtain code coverage for an embedded project would be to use Segger J-Trace (see this tutorial).
Thanks for sharing your list of commonly used warnings. We have reviewed them and added most of them them (except for the -Wno-psabi that appears too specific) to the VisualGDB GUI. Please try this build: VisualGDB-5.5.2.3372.msi
The C++-only warning options will be automatically dropped for Plain C files. Let us know if you have further feedback/suggestions.
Your current workaround with generating the scripts based on the .rsp files is reasonable. That’s what we usually suggest doing if you need to build an MSBuild-based project outside VisualGDB. The new CMake project subsystem will indeed eliminate the need for it.
Hi,
Looks like you have skipped the “/solution:” prefix before the solution file. Please double-check the command line shown when building the project in Visual Studio and ensure it 100% matches the command line in the CI setup.
Hi,
It looks like you are setting the $pc to an incorrect value (the address of the interrupt vector table rather than the reset handler). Instead you would need to parse the interrupt vector table and extract the reset handler address from it (see ARM Cortex-M3 documentation for details). Alternatively, please consider programming the ELF file instead. Its header explicitly contains the entry point address and most tools automatically set $pc accordingly when loading ELF files.
No worries and good to know it works. As we don’t know the internal structure of your project, it’s hard to comment anything regarding the solution, but just a heads up that you can use the VisualGDB GUI to edit the public includes of a target via the “Exported Settings -> Public” page of its VS Properties window.
Hi,
Although we have not explicitly tested this configuration, you should be able to target the M0 core of the dual-core NXP devices by using Segger J-Link with the J-Link software. It allows pickingbetween the _M4 and _M0 device variants in the device selection GUI. If you would like to use OpenOCD instead, you might be able to tweak its scripts to connect to the M0 core as well, however we have not tested this on our side and unfortunately cannot provide exact instructions.
Hi,
No problem. We have updated the C/C++ standard list in the following build: VisualGDB-5.5.2.3363.msi
Regarding the other suggestions:
- We generally don’t recommend using GNU Make as it does not automatically handle long command lines (i.e. doesn’t provide an easy way to generate response files without running into the same command line length limitation). Our MSBuild back-end is designed to handle this automatically, and is also highly optimized compared to GNU Make. If you could let us know why you are trying to convert an MSBuild project to GNU Make, we should be able to suggest a better solution.
- We have added support for most commonly used GCC warnings to VisualGDB 5.5 (see C/C++->Warnings). Generally we want to avoid adding all of the warning options from the GCC documentation to avoid overloading the window and making it hard-to-navigate. However, if you could let us know the specific warning options you are commonly using (and other GCC options not covered yet), we will be happy to update the VisualGDB GUI to include them. You can also try tweaking the <VisualGDB Dir>\Rules\PropertyEngine\Common\cflags.prop file to your liking. It will immediately affect CMake projects and you can send us your changes if you would like us to propagate them to MSBuild projects.
- Regarding the static libraries, we are currently designing an experimental CMake-based embedded project type that will greatly simplify the use of static libraries, targeting multiple devices from the same project, etc. We will include it in one of the next preview builds of v5.5 over the next few months.
Hi,
We started shipping our own ARM toolchain (arm-eabi) when the official GNUARM toolchain was still relatively buggy and did not work with many SDKs (e.g. some standard library FP functions were chosen incorrectly for some CPU/FPU combinations). Over the years the quality of the official toolchain has improved, so VisualGDB now supports it out-of-the-box.
Generally, if you are looking for the latest C++ features, we advise using the latest GNUARM toolchain. As soon as you install it and restart Visual Studio, VisualGDB will automatically detect it and will let you create projects with it. If you encounter any issues, please feel free to let us know. As long it could be mitigated on the VisualGDB side, we should be able to fix it.
If instead you would like to minimize the chance of incompatibilities between the toolchain and BSPs and don’t care about the latest GCC functionality, the arm-eabi toolchain would be you safest bet.
We are gradually switching to the GNUARM toolchain in our internal BSP tests and once we get enough confidence with it, we will deprecate the arm-eabi toolchain and make the GNUARM toolchain the default choice.
