Forum Replies Created
-
Posts
-
Good to know it works. As OpenOCD is a separate open-source tool that is independent from the regular ST-Link tool, this makes sense. That said, aside from occasional issues with the STM32L4 FLASH driver, OpenOCD is pretty reliable and usable.
The TestFramework.mak file would normally only be referenced when creating unit test projects, or referencing unit test frameworks. Either way, please try searching the Makefile and *.mak files for the “TestFramework” text and remove any references you find. If nothing helps, simply re-creating the project from scratch should solve the problem.
Hi,
Please use VisualGDB Project Properties -> Unit Tests page to remove the dependency to the test framework.
No problem. BTW, feel free to let us know if you pinpoint a specific file (e.g. a linker script) that is causing the issue. As long as it doesn’t break backward compatibility with existing projects, we can easily update our BSP so that you won’t need to replace any files manually.
The ‘@’ syntax definitely works from the regular command prompt. We use it all the time when running pre-release tests on new BSPs and creating custom project templates via our consulting track, so it usually takes less than 10 iterations to find the root cause even for massive projects with very complex settings.
No problem, we can help you get it to work.
Each Linux command executed by VisualGDB runs in a separate shell instance, hence the ‘ulimit’ command specified via the pre-debug steps won’t affect the program (as it will run in a separate shell).
Instead, please try changing the GDB command on the Debug Settings page to the following:
- Command: ulimit
- Arguments: -s <new size> && gdb –interpreter mi $(TargetPath)
- Start debugging with: “run” command
This will launch gdb in the same shell instance as the ulimit command, so it will take effect as desired.
Hi,
VisualGDB allows specifying per-project library directories (see VisualGDB Project Properties -> Arduino -> Extra library directories), so you should be able to achieve the same outcome by using this setting.
If it it doesn’t work, please let us know and we will help.
We also have long-term plans for supporting PlatformIO projects with VisualGDB as well, although it’s hard to name a specific timeline for it yet.
Thanks for the detailed update. Looks like you forgot the ‘@’ symbol before the path to the response file. I.e.
arm-eabi-gcc @.\EmbeddedProject3.link.rsp
instead of:
arm-eabi-gcc .\EmbeddedProject3.link.rsp
Without the ‘@’ symbol, gcc will try to treat the .rsp file as a regular C/C++ source, leading to weird errors. Also normally, you would want to run it from the project directory (some paths in the .rsp file can be relative to it), so the command line will most likely look like this:
arm-eabi-gcc @VisualGDB\Debug\EmbeddedProject3.link.rsp
It could be also something as subtle as a bug in a specific softdevice version, so please ensure that both projects use exactly the same SDK sources/headers (i.e. physically the same files) and the same softdevice binary.
Sorry, we would still need specific steps to reproduce it. You don’t need to attach a whole project, just the contents of the source file (s), the exact place where you trigger the code completion and what do you expect to see vs. actually see will be sufficient.
From the OpenOCD point of view, ST-Link v3 is backward compatible with the previous versions, so simply selecting one of them on the Debug Settings page should work (you will need to switch from USB Devices view to Debug Methods view in order to do that).
We have also added USB VID/PIDs for ST-Link v3 to the device definitions in our development branch, so the next version of our OpenOCD package will recognize them automatically.
Sorry about that. For regular (non-stand-alone) projects there is no redundancy between different types of settings, as we specifically design our BSPs so that the settings specified there do not conflict with the regular VS project properties. The stand-alone projects do give you full control over all flags specified on the BSP level, however it indeed creates a possibility for conflicts.
That said, you don’t need to remember a checklist of flags – simply check VS Project Properties (not VisualGDB Project Properties) -> Configuration Properties -> C/C++ -> Command Line and you will see a detailed list of flags derived from the VS project properties (that will normally override any similar flags from the BSP).
Unfortunately, the exact names of conflicting settings are slightly different between the GCC versions (e.g. newer versions introduce more optimization levels or debug format levels), so reliably checking for all possible conflicts would be a relatively complex and error-prone task. As the scenario you described is relatively rare, we are happy to update the documentation and help you understand the exact logic behind this, however we would like to avoid introducing complex error-prone logic for handling it fully automatically, sorry.
Hi,
Unfortunately the specific connectivity issues you described are indeed beyond the bounds of the regular VisualGDB support, however we can explain what is going on from the VisualGDB’s point of view and suggest some ideas to diagnose it:
- The “stray ‘\'” error happens because VisualGDB tries to compile an assembly file (.S) as Plain C file (following your settings). You can fix this by resetting the “compile as” setting for the .S files (either to default or specifically to preprocessed assembler). The per-file settings will override the per-project setting.
- Normally, you don’t need the “Compile as” option at all, unless you specifically want a file with the .cpp extension to be compiled as a plain C file (in that case, simply changing its extension to .c would have the same effect and a much lower chance of causing confusion in the future).
- As long as you are using C++ without exceptions/RTTI, it should not affect the behavior of other code in the project.
If we understood you correctly, you currently have a project that works and a project that reliably fails (both don’t have any C++ files). We would advise trying to understand the differences between the 2 projects and eliminating them one-by-one, doing a check at each step. Most likely, the difference comes from a slightly different preprocessor macro, different linker script, or even a different order of inputs (unlikely, but sometimes happens).
You can find the command lines used by VisualGDB in the .rsp files inside <project directory>\VisualGDB\Debug. Running arm-eabi-gcc @<path to the rsp file> will result in GCC executing the command line stored in the .rsp file. Please try running those command lines manually (via a bat file) and confirm that the 2 project outputs still behave differently. Then try combining the linker command line from 1 projects with the object files produced by another project. This will show whether the problem happens during linking or compilation. If the problem is due to compilation settings, try pinpointing a specific file by replacing half the files at a time. Once you get to a specific command line, you can repeat the same approach (eliminate half the differences at a time) to quickly identify the exact command line argument that triggers the problem.
Hope this helps. Let us know if you need more details and we will be happy to help.
Sorry, there are no links to the solutions because nobody else has reported anything similar in the past 7 years.
If you would like our help to solve this, please follow exactly the steps below:
- Check if this can be reproduced on a freshly created “LEDBlink” project.
- Check if the problem can be reproduced on a non-VisualGDB C++ project.
If the problem is not specific to VisualGDB projects, it might be caused by something else (you can double-check it by uninstalling VisualGDB). If the problem is specific to VisualGDB projects, please create a video showing the repro, from starting Visual Studio to the problem actually occurring.
No problem. If you get time to attach a screenshot, or a quick video showing the problem, we should be able to help. Unfortunately the description you provided so far, still matches about 5 different problems with completely different steps to diagnose and you probably don’t want to go through them all.
