[support]

Sorry, we tried helping our users with such issues before, but it always backfired. Users would then run into much bigger problems further down the road, and would expect our support to review complex schematics of custom boards, or look through large projects written by someone else, that somehow interfere with debugging logic.

So, we had to limit our regular support to issues that are specific to our tools. If you would like us to explain anything else, we can do it at our consulting rate. You can read more about it here.

[support]

Hi,

Based on what you described,  it looks like a wiring issue. Please refer to your board and JTAG debugger documentation for details on getting the wiring correctly. VisualGDB cannot automatically fix it for you, or troubleshoot any wiring issues.

If you are not sure, please make sure you can debug the same board with the same example by running OpenOCD manually. If it works outside VisualGDB, we can help you configure VisualGDB to match that setup. If the board doesn’t work outside VisualGDB either, you will have to figure it out first before trying VisualGDB.

[support]

Hi,

We are aware of the new STM32H7S series and have the BSP based on the official SDK from STM32, however have not tried the hardware on our side yet.

If you would like to replicate the 2-project structure from STM32CubeIDE, we would advise using the Advanced CMake Project Subsystem to create the bootloader + application projects separately, and then manually combine them into the same project by editing CMakeLists.txt. Specifically you would need to:

• Move the find_bsp() statement from the second project into the first one, adding an ALIAS parameter (e.g. BSP2)
• Move the add_bsp_based_executable() statement as well, setting BSP_ALIAS to match the second BSP.

You can also just create 2 separate MSBuild projects and have them in the same solution (right-click on Solution node -> Add -> Existing Project).

We do not have the hardware yet to give exact advice on replicating the ExtMemLoader logic (we will be publishing a tutorial in a couple of weeks), however, you can try checking what exactly does the STM32CubeIDE do in this mode. If it’s running OpenOCD with some special arguments, or executing the STM32CubeProg, we can help you configure VisualGDB to match that.

[support]

Hi,

Thanks, looks like the new preview build introduces additional type checking that fires false positives in some cases.

We have added a workaround to this build: VisualGDB-6.0.104.5221.msi

[support]

Hi,

You can configure VisualGDB to use esptool.py to load the FLASH memory even when debugging with OpenOCD. This can be done via VisualGDB Project Properties -> Debug Settings -> Program FLASH using -> esptool.py.

Then, VisualGDB will run the FLASH programming command before starting debugging (on latest ESP-IDF that would be ninja flash) that internally runs esptool.py with the correct settings. You may need to change some project settings in the CMakeLists files to enable the encrypted mode for this command (you can try asking on the Espressif’s forum).

Another option is to disable the FLASH programming via VisualGDB Project Properties, and run explicitly esptool.py via pre-debug steps or custom actions (requires Custom Edition).

[support]

Thanks for your patience. We have added the option to auto-complete only with TAB to VisualGDB 6.0R4.

You can configure it via Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Auto-complete only on TAB.

[support]

Hi,

No problem, please find the detailed answers below:

1. VisualGDB offers a different set of refactoring tools from the regular VS. E.g. it has the create-from-use functionality that normally only works for C# projects, but doesn’t have the “extract function” feature. Other refactoring features are implemented via RefactorScript – an extensible scripting language for generating boilerplate code. If you are looking for a particular refactoring feature, let us know and we will advise how to find it.
2. This looks like the memory buffer in the program gets corrupt, so VisualGDB cannot make sense of what it’s getting from the target. Just overflowing the buffer should not be causing it. Please try reproducing the problem on a clean project created from scratch. If it doesn’t happen there, please try comparing it against the original one.
3. Normally, address resolution should work. Please try checking it with a clean project created from scratch. If it works there, but not on the actual project, it could be caused by inconsistent debug symbols in the project, or by a bug in the VisualGDB’s profiler. If this is the case, we can investigate it further if you could share your ELF file. We would kindly ask you to renew your support first though.
4. We have rechecked it and it worked just fine. If it doesn’t work as expected, please make sure you can reproduce the issue on a clean project created from scratch, and then share the complete repro steps as described here. You can also record a screen video showing the problem if you do not want to take multiple screenshots.

[support]

Hi,

We haven’t checked the RP2040 specifically, but most similar devices support between 4 and 6 hardware breakpoints. You can probably find out the exact number in the datasheet, or just try creating several breakpoints and see how much it takes to trigger the “too many” error.

[support]

Hi,

You can use the virtual folders in Solution Explorer (similar to regular VC++ projects) or CMake source groups (requires editing CMakeLists.txt files, but will work with any IDE that uses CMake).

That said, the STM32CubeMX-based projects have a somewhat rigid structure where many parts gets regenerated when you change settings in the STM32CubeMX tool, overwriting the changes that were outside the specially marked blocks. We do not recommend this workflow for complex projects with non-trivial structure. Instead, we would advise having 2 projects:

• A simple STM32CubeMX project that has all the relevant initialization/configuration code generated by the STM32 tools.
• The main CMake-based or MSBuild-based project with production code, that has snippets copied from the STM32CubeMX project.

 

[support]

Hi,

Thanks for confirming this and sorry for the confusion. Dragging files works for virtual folders, when the physical files remain in the original location and the only thing changed is the view in Solution Explorer.

Physically moving files to different folders cannot be directly done via Solution Explorer, and needs to be done manually (i.e. remove files from the project, move them via Explorer, and re-import them back either manually or via Import Folder Recursively command). The main reason for this limitation is to be consistent with the regular VC++ projects where moving files in Solution Explorer never changes their physical location. If VisualGDB implicitly moved files instead, it could easily introduce build errors (e.g. when using relative paths to headers).

[support]

Hi,

You can try recording a quick video of the problem using Windows Game Bar, and sharing that. It should help see what is going on.

[support]

Hi,

Sorry, looks like your kernel headers are corrupt and building modules with them won’t work.

[support]

The OpenOCD error looks like some of the debug plugins got cached incorrectly. Restarting Visual Studio should solve it.

Drag-and-drop between folders should normally work, unless you are trying to move files generated by STM32CubeMX. These files are intentionally non-movable, because re-running STM32CubeMX would re-generate them under old paths, creating conflicts between the new and old versions. If you are 100% sure you will not need to do that, you can create a regular CMake-based project, move the STM32CubeMX-generated code into it, and then most usual editing functionality will work just fine.

 

[support]

Hi,

Thanks for sharing this. Normally, the project reloading should not effect the logic that manages VisualGDB Project Properties, but given the overall complexity of VS, it could have cached something in a way that would interfere with VisualGDB.

If anyone else encounters the problem and confirms the workaround, we can investigate it further and see if VisualGDB can detect it automatically.

[support]

Hi,

VisualGDB indeed does not have a separate menu command for creating physical folders. However, it will recognize the actual folders where the sources are located. E.g. you can try clicking Add->New Item, and appending “\subfolder” to the Location field. VisualGDB will automatically create subfolder, will place the new file there, and will show it in Solution Explorer.

We have rechecked the Group Sources by Types setting and it worked just fine – hid the Source files and Header files nodes as expected. Please try checking it on a newly created project without changing any other settings. If it works there, please try comparing the 2 projects to see if there is any other setting you could have changed that triggered this behavior. Please also make sure the project is saved after you change the setting. If you close Visual Studio without saving the solution/project, the setting will not be saved and VisualGDB will revert to the old behaviour next time you open the project.

[Author]

Posts