[support]

Hi,

Sorry, this issue happens because Visual Assist does not recognize Clang IntelliSense-powered projects as compatible projects and hence doesn’t work with them. The only way to resolve it would be to get the Visual Assist vendor to update their code to recognize VisualGDB projects. We are willing to provide any necessary assistance from our side to get this to work, however it would still require a change on their side.

[support]

Hi,

Thanks for clarifying this. If set can-use-hw-watchpoints affects the behavior, it is indeed caused by the target limitations (e.g. the kernel might not be allowing the user-mode code to access debug registers required for hardware watchpoints). We would advise trying to run gdb on the target manually with a test program. If the hardware breakpoints work there, the problem might instead be caused by an incompatibility between gdb an gdbserver, and trying a different combination of those components might solve it.

[support]

Hi,

Unfortunately it’s a bit more complicated. VS2017 uses private registry files that need to be programmatically mounted before you can make modifications to them. We could easily provide example code for doing that if you would like to try it out.

[support]

Hi,

Looks like you are using a relatively old build of OpenOCD. Please try upgrading to VisualGDB 5.4 Preview 5 and install the latest OpenOCD package via VisualGDB Package Manager.

[support]

Hi,

Sorry, this is by design. The “Device-specific files” filter is reserved for the files from the BSP that are automatically managed by VisualGDB. E.g. when you change the MCU type or add/remove frameworks, VisualGDB may replace the entire contents of that filter with the files specified by the current BSP version. The template logic also follows this convention – it stores the device ID and settings and re-creates the contents of device-specific files based on the BSP definition. I.e. if you use the same template with a later version of the BSP, it will still use the correct list of files from the new BSP.

Unfortunately it is somewhat confusing as the “Device-specific files” filter is not shown differently from other filters due to the limitations of the VC++ project subsystem. Long-term we are planning to switch our embedded projects to the Advanced CMake Project Subsystem, so VisualGDB will have fine-grain control over the contents of the Solution Explorer and will be able to clearly show which files are automatically managed by VisualGDB.

[support]

Hi,

Thanks, this looks like a problem that was recently fixed internally. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2443.msi

[support]

Hi,

Strange, the log looks like exactly the same error that was fixed previously is triggering again. Please try again with this build and let us know if the issue is still present: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2443.msi

[support]

Hi,

We have rechecked this and it looks like VS overrides the line endings passed to it by VisualGDB. We will investigate further and will try to add a workaround, however this will be done after the upcoming Preview 5.

As a temporary workaround, please let Visual Studio normalize the line endings when you open the files (or configure git to always commit the specified line ending style if you are using it).

Update: we have found the root cause of it and it traces back to one of the components used internally by Visual Studio [details]. We have tried several workarounds, however they all have considerable negative side effects due to the way VS handles the snippets internally. Hence unfortunately we won’t be able to add any VisualGDB-level workaround for this and would advise relying on Visual Studio or your source control system to automatically normalize line endings, sorry.

• This reply was modified 6 years, 11 months ago by support. Reason: Pinpointed the root cause

[support]

Hi,

Thanks for reporting this. We have rechecked the VS2015 setting exporting logic and it indeed looks like it skips the custom language service settings (such as VisualGDB) by default. As fully fixing this would require a relatively large investigation/change on our side, we would instead suggest using one of the workarounds below:

• First of all, you can change the values via registry (HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0\ApplicationPrivateSettings\TextEditor\C/C++ (VisualGDB))
• Alternatively, if you are using the VisualGDB’s team settings engine, we could extend it to share the common Clang IntelliSense settings

Let us know if you would like us to extend the team settings engine to handle this.

[support]

Hi,

This looks like a known OpenOCD issue – some combination of section sizes and alignment causes it to fail the FLASH programming on STM32L4 devices. Please try checking the section sizes/alignments in Embedded Memory Explorer and see if increasing the alignment via the linker script (e.g. aligning every section to 16 or 64 bytes) solves the problem.

Another option would be to use Segger J-Link instead of OpenOCD. The J-Link comes with its own highly optimized gdb stub that handles memory programming better than OpenOCD, works faster and supports software breakpoints in FLASH memory.

[support]

Hi,

This might be caused by VisualGDB not determining the variable address correctly, or by the target simply not supporting memory breakpoints.

Please try running the gdb’s watch command manually via the GDB Session window. If it doesn’t work either, your target may not support it. Feel free to let us know the target type (Embedded/Linux/Android) and the debugger configuration (direct/gdbserver) you are using so we could suggest a few other things to try.

If watchpoints work when created manually, but don’t when created with VisualGDB, please try setting them using both ways and send us a diagnostic GDB log showing both the commands entered manually (that work) and the commands issued by VisualGDB (that don’t) so we could see what could be causing the difference.

[support]

Hi,

This is likely caused by a missing setting, or an incompletely imported project. We can help you get it to work if you could share the details we requested.

[support]

Hi,

This is likely caused by a missing setting, or an incompletely imported project. We can help you get it to work if you could share the details we requested.

[support]

Hi,

It looks like you are using the “Cortex-M7 with MPU (memory protection unit)” port of FreeRTOS. If this is intended, you would need to provide implementations for MPU-related functions and linker-level symbols setting boundaries between protected and unprotected regions (VisualGDB doesn’t provide any default implementation for this, so the best starting point would be the STM32 examples).

If this is not intended, please simply select the regular M7 (not M7 with MPU) port via VisualGDB Project Properties -> Embedded Frameworks.

 

[support]

Hi,

The ESP32 app trace feature is already supported out-of-the-box. As long as you are using OpenOCD and enable it on the Embedded Debug Tweaking page, VisualGDB will display the output from the ESP32 apptrace inside Visual Studio.

[Author]

Posts