Forum Replies Created
-
Posts
-
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.
No problem. We have updated VisualGDB to show the output messages from TinyEmbeddedTest in Test Explorer. Please try the following build: VisualGDB-5.5.2.3357.msi
Please make sure you update to the latest Profiler/Semihosting and TinyEmbeddedTest framework versions after installing the new build. Then try creating a simple TinyEmbeddedTest-based project and run its tests. The test window will show the output from test #2.
We have also added an option under VisualGDB Project Properties -> Embedded Frameworks to redirect all regular printf() output to the test output.
Sorry for the delay. We have done some experiments and added a target API that allows distinguishing between the regular debug sessions (launched via Debug->Start Debugging) and test run/debug sessions launched via Test Explorer.
Please try the following build: VisualGDB-5.5.2.3357.msi
Please also update the Semihosting/Profiler and TinyEmbeddedTest frameworks via Tools->VisualGDB->Manage VisualGDB Packages after installing the new build.
Then try creating a new TinyEmbeddedTest project and see how RunAllTests() is now called conditionally:
if (IsRunningUnitTests()) RunAllTests();You can use the IsRunningUnitTests() call in your code to switch between running the main application logic and passing control to the test framework.
If you would like to remove the tests from the final binary, please consider creating a separate configuration (e.g. Debug + Tests), defining a macro (e.g. INCLUDE_UNIT_TESTS) via VS Project Properties and checking for it in your code.
Hope this helps. Let us know if you have any further questions or suggestions.
Hi,
Sorry, our external FLASH plugin mechanism is only intended to be used with VisualGDB. It will not work with the ST-Link programming tool, or any other software.
If you are using VisualGDB, you can program the FLASH memory without launching a debugging session via Debug->Start Without Debugging or Debug-> Program FLASH Memory.
Regarding the external memories, you can indeed get it to work by modifying the linker script manually, however you would need to make sure you fully understand the linker script logic first, as incorrectly using some of the linker script parameters would make the built file unusable.
If you prefer something that works out-of-the-box, please consider upgrading to VisualGDB Custom Edition here and then use the External Memories page of VisualGDB Project Properties to automatically edit the linker script as expected.
No problem, we can help you get this to work, however we would need more information in order to pinpoint it.
The error stack you attached looks like the New Linux Configuration Wizard is getting invalid/incomplete information about the current project. If the solution contains multiple projects, it could happen if the currently selected project (i.e. the project owning the currently selected item in Solution Explorer) is some special type of project that is not properly recognized by VisualGDB.
In order to diagnose it further, please try this build: VisualGDB-5.5.1.3349.msi, it should include more details in the error traces.
Please share the updated traces from:
- Using the New Linux Configuration wizard
- Using the New Linux Project wizard
If you could also share a screenshot of the Solution Explorer showing the currently selected item while trying to import the project, it can help us pinpoint the issue faster (you can send it via our support form if you don’t want to post it publicly).
Hi,
Sorry, the embedded test frameworks also require the profiler/semihosting framework, that needs to be enabled separately via VisualGDB Project Properties -> Embedded Frameworks.
Generally, we would advise creating a new test project from the wizard. Now that you have the Custom edition, it should work out-of-the-box, referencing the necessary libraries generating the necessary initialization code.
Once you can confirm that testing a newly created project works, please try referencing both the profiler framework and the unit test framework from the existing project and then ensure its main() function looks similar to the main() function of the generated test project.
