Forum Replies Created
-
Posts
-
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.
Sorry, unfortunately it looks like the detail level you require is beyond what we can offer with our product support. VisualGDB is a productivity tool that automates common development tasks and provides convenient GUI for common routine operations. However, it still relies on the understanding of basic programming concepts and the ability to troubleshoot issues inside the code or build scripts that do not come from us.
While we are happy to point to a VisualGDB setting that allows specifying the PATH variable, it is beyond the scope of our support to suggest a specific path string that will work with a specific project.
We are sorry if this is not what you expected from our support, however we have to find a trade-off between covering underlying low-level tools while charging 10x-20x more per license, and restricting support to VisualGDB issues only while keeping our product price more affordable. We do offer paid consulting with hourly billing to bridge the gap between the 2 options, however it isn’t possible for us to provide this level of detail at the price of a regular license.
This means that the gcc executable is not in the PATH variable.
Please try running the “arm-none-eabi-g++” from the bash command line, take note of its location (directory containing the executable) and add the following environment variable to VisualGDB Project Properties -> Build -> Build Command -> Environment:
PATH=%PATH%:<directory containing arm-none-eabi-g++>
This is likely a VisualGDB bug caused by a recent change in the WSL path mapping logic.
Please try the new build linked in our previous reply (VisualGDB-5.5.1.3339.msi). We have removed the Source Code Access page for Linux Subsystem projects there to avoid any confusion, so the bug should no longer trigger.
If you know the directory where the Makefile is located, please simply select the following:
- Project Type: Import a project -> Import a project built with other tools
- Source code location:
- The sources are located under the Linux root filesystem
- Source directory: the directory where you have the Makefile (Linux-style path such as /mnt/c/foo)
- Building and debugging:
- Build command: make
- I don’t know the main executable yet.
The “Source Code Access” page is intended for setups involving Linux machines accessed via network and can be ignored when using LXSS.
We have not anticipated it to cause that much confusion and have removed it for imported Linux Subsystem projects in the following build: VisualGDB-5.5.1.3339.msi
Please try the new build, it should make the importing process very straight-forward.
