[support]

Hi,

The command line shown on 2.png looks identical to the one you shared in the previous reply, so it should work the same way.

Please try restarting your computer, make sure no other program is using JTAG, and then try the following steps:

• Try using the test button in VisualGDB Project Properties. If it succeeds, you should be able to debug.
• If it fails, copy the exact command line shown there, and run it from cmd.exe.
• If running it manually fails, try comparing it to a working command line. Perhaps, you need some additional parameters, or have to launch it from an Administrator prompt.

[support]

Hi,

Sure, please try switching from the “USB Devices” view to the “Debug methods” view in VisualGDB Project Properties -> Debug settings, and then pick Segger J-Link there. It will bypass any device-level checks and will let VisualGDB run the J-Link GDB server directly.

[support]

Hi,

Sorry, it is still not supported with the latest toolchains. We initially added this feature when the pre-built ARM toolchain was somewhat buggy, so we were patching it and rebuilding it on our side. Over time, ARM resolved these issues, so we switched to testing the binaries published by ARM, wrapping them with configuration files, and publishing them as ready-to-use packages.

In the recent years, ARM has changed the mechanism used for building their toolchain several times, resolving some issues and introducing others. As of April 2023, the prebuilt GNU ARM toolchain does not have official instructions for building a Windows toolchain. We were able to build a usable toolchain by slightly modifying their Linux building instructions, however it looks slightly different from the Windows binaries published by ARM, so looks like ARM is using some undocumented internal process for building their toolchain.

As the vast majority of frameworks and SDKs are tested with the pre-built ARM toolchain, we do not want to risk introducing incompatibilities with it, and will stick to shipping repackaged versions of the ARM toolchain binaries until ARM publishes their official Windows build pipeline.

If you absolutely want to step through the newlib sources, you may need to build it from scratch with the debugging symbols for newlib enabled. The exact steps vary between different ARM toolchain versions, so the best place to ask for them would be the ARM forum.

[support]

Hi,

Thanks, we have reproduced the issue. Turns out the 3rd-party RP2040 Arduino port you were using relied on a rather rare syntax form to pass the include directories to GCC, so VisualGDB was not catching it automatically. We have updated VisualGDB to handle it correctly. Please try this build: VisualGDB-5.6.109.4854.msi

BTW, we also added the RP2040 port to the list of the 3rd-party ports automatically shown by VisualGDB in the device list, so you won’t need to add its package index file manually.

[support]

Hi,

IntelliSense should work just fine out-of-the-box, unless you have already modified some settings that would interfere with it.

Please try creating a new project from scratch. If the problem persists, please share the full steps to reproduce the issue from scratch:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
4. Please also provide a screenshot of the Help->About VisualGDB window so that we could ensure we are checking it on the same version

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines.

[support]

Hi,

No problem. We have also added another tutorial showing how to discover statically defined objects (i.e. global variables of given types) and dynamically created ones as well (by traversing linked lists).

If you absolutely do not want to deal with C#, you can try using IronPython – it allows creating .Net objects and implementing .Net interfaces using Python. You will get to use the Python syntax instead of C#, but the rest of the functionality (implemented interfaces, general semantics, etc) will be the same. There is also Python .Net, although it appears to mostly target a different use case.

If this doesn’t work and you would like us to develop a completely custom scripting engine based on your requirements, we can do it as a paid custom feature. Feel free to draft a specification showing the features you would like to see, and we can give you a quote. We can also schedule a call to discuss the requirements, prepare a spec draft, and send it to you for review. Feel free to reach out to our sales if you would like to explore this direction, and we will try our best to find a solution that will work.

[support]

No worries. Complex problems almost always have multiple causes, and simplifying the repro scenario always helps separate them.

If you encounter further issues, feel free to create another thread and we will be happy to help you.

[support]

Thanks, we have reproduced the issue with the bsp_compile_definitions() and other similar statements. Indeed, they expected the ALIAS keyword instead of BSP_ALIAS as per documentation.

We have updated VisualGDB to handle both keywords in this build: VisualGDB-5.6.109.4853.msi

That said, we could not reproduce the issue with the flags applied to both BSPs. If it still persists with the new build, please try reproducing it on a sample STM32-based project and share the updated repro file.

[support]

Hi,

The ARM64 compatibility should not affect firmware downloading. The regular F5 command may not work for some project types, but the Debug->Start debugging with GDB should work.

Can you confirm that the project build speed is reasonable and that running J-Link GDB server with the command-line gdb works as expected? If the underlying tools do not work on ARM64, resolving the VisualGDB issues won’t automatically fix it.

[support]

Hi,

OK, we have published a detailed reference covering the live watch plugin API here: https://visualgdb.com/reference/extensibility/html/N_VisualGDBExtensibility_LiveWatch.htm

We also published 2 tutorials that should help anyone interested get started with Live Watch plugins:

• Creating a basic Live Watch plugin
• Creating custom Live Watch nodes

We will publish another tutorial on discovering multiple objects and iterating lists next week.

The tutorials assume no prior C# knowledge, so they explain all key concepts, show how to use Visual Studio to setup the projects, add classes, etc. They also cover the non-trivial C# syntax that is different from C++.

If you have any feedback regarding the new documentation, feel free to post it here.

 

[support]

Hi,

The first code snippet you posted should work just fine. You can retest it by creating a simple STM32 project and copying it there.

If it’s not working in a more complicated McuXpresso project, the issue is likely caused by some hard-to-see difference (e.g. a space in some identifier that breaks CMake argument order). The easiest way to narrow it down would be to use the CMake debugger to step through a working STM32 setup and a broken McuXpresso setup side-by-side, until the difference becomes obvious.

[support]

Thanks for sharing this. BTW, we have published a tutorial showing how to use the ST-Link GDB server with VisualGDB here. We will watch for feedback on it and will consider creating an out-of-the-box debug package for it, similar to the OpenOCD one.

[support]

Hi,

Please let us know the email address associated with your license key, so that we could check your support status.

[support]

Hi,

Thanks for renewing your license. We have investigated and fixed the issue. Please try this build: VisualGDB-5.6.109.4849.msi

[support]

Hi,

We have not tested it on our side, however you can easily try it out by creating an MSBuild-based project and switching from the Clang IntelliSense to the regular VC++ IntelliSense.

Such project will look like a regular VC++ project from the Visual Studio side, so any extensions that work with the regular VC++ projects will work with it as well.

[Author]

Posts