Forum Replies Created
-
Posts
-
Hi,
Yes, the embedded RTOS plugins require the Custom edition or higher. Starting with v5.2 the plugin is shipped with VisualGDB and can recognize FreeRTOS-based projects automatically from looking at the symbols, so as long as you are using the correct edition, no manual configuration is needed anymore.
Hi,
The “Error: JTAG scan chain interrogation failed: all zeroes” error almost always means wiring issues. Please double-check your connection, ensure no other peripherals share the JTAG lines. If nothing helps, please try using a logic analyzer to see if there is any JTAG activity on the corresponding pins.
Hi,
It should be on the Debug Settings page of VisualGDB Project Properties. If not, please attach a screenshot of this page (we have recently added attaching functionality to the forum) and we will advise.
Hi,
The Program Files directory is normally not writable (unless you launch VS as Administrator which is often not the case), so we store the downloaded files under $(LOCALAPPDATA).
We intentionally don’t pre-install ALL of the BSPs with VisualGDB as they often get updated and none of our users will probably need ALL of the BSPs for ALL supported platforms at the same time.
The STM32 BSP is indeed huge, but as the modern HDDs/SSDs are huge as well and the scenario of one computer/multiple users is relatively rare, we don’t want to change the current layout. As a possible quick workaround we could recommend creating symbolic links between the BSP directory under %LOCALAPPDATA%\VisualGDB and a shared BSP location outside the users’ appdata directories.
BTW, we are currently experimenting with storing $(BSP_ROOT) paths in the .vcxproj files instead of the relative paths to relocated BSPs and are planning to include this in the upcoming Preview 3 of v5.3. This should solve the problem you mentioned.
Hi,
Normally, checking the VisualGDB Diagnostics Console for the exact list of commands executed by VisualGDB adn re-running them manually should explain what is going on. Most likely some of the system tools (like gdbserver) got corrupt and resulted in invoking ld.so instead.
Hi,
This could be related to a recently fixed bug in the 64-bit engine. Please try downloading this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.2.1620.msi
If the crashes still happen, please try deleting the CodeDB directory and reopening the solution.
Hi,
Yes, you can relocate the BSP as shown in this tutorial (requires Custom edition): https://visualgdb.com/tutorials/arm/multiuser/
Hi,
Looks like the image did not get uploaded properly. Could you please try attaching it to the post via the “attachments” button below?
Hi,
You can enable it via Tools->Options->Text Editors->C/C++ (VisualGDB)->Other->Use 64-bit Clang Engine. Note that you will need to reopen your solution in order for this setting to take effect.
Hi,
Thanks for reporting this, looks like our bug. We have updated our profiler package. You can download it via Tools->Manage VisualGDB Packages.
Hi,
The problem with converting an arbitrary Makefile-based project is that different Make-based projects store settings like CFLAGS slightly differently, so extracting them fully and reliably quickly gets too complicated. We have long-term plans for a tool that would reconstruct a project based on build logs (showing all gcc invocations), but it will not work on 100% of projects as Make projects often include custom build steps.
We have checked the internals of cmake-cli and will contribute an exporter module that will construct a VisualGDB project (similar to what it does for IAR projects) if the mbed community is OK with this.
Hi,
The “launching custom program console” could be related. Please check the corresponding setting under VisualGDB Project Properties -> Custom Debug Steps. You might be accidentally launching ld.so as the custom console command.
Hi,
This is a known issue caused by a breaking change in the kernel 4.10. As a workaround, please try downgrading to an older kernel before we fix this.
