Forum Replies Created
-
Posts
-
OK, we have added a setting for this: Tools->Options->Text Editor->C/C++ (VisualGDB)->Advanced->Code Completion->Additional suggested C++ keywords.
Please try this build: VisualGDB-5.4.104.3057.msi
Sorry, there is no other place other than the .mak files in the project’s directory where ADDITIONAL_MAKE_FILES would be set.
If you are still getting strange errors, please try creating another project from scratch – it should rule out any accidental Makefile modifications that could be causing this.
No problem, please try this build: VisualGDB-5.4.104.3057.msi
We have added an option under VisualGDB Project Properties -> Arduino to ignore the default library paths.
Thanks for sending us the repro project. We have fixed the issue in this build: VisualGDB-5.4.104.3057.msi
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.
