[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.

[support]

Hi,

The problem you are describing involves 6 different components:

1. The actual board
2. The firmware running on the board
3. The JTAG debugger
4. The OpenOCD tool that talks to the debugger
5. The Arduino package that contains rules for building the software
6. VisualGDB used as a GUI on top of this

The role of VisualGDB here is to provide convenient GUI for automating common development tasks. E.g. the graphical editor for the KConfigs with convenient search and grouping, automatic editing of CMake files, etc. The underlying components come directly from hardware vendors, Arduino community, etc. They sometimes have bugs, and sometimes have incompatibilities between different versions. We do not charge you anything for using them. We do not require that you buy a JTAG debugger from us, a specific board from us, use only libraries approved by us, etc. Hence, if some of these external components don’t work as intended, it’s generally up to you to figure it out.

We try to be fair: if you can get debugging to work with the same board using the same Arduino package outside VisualGDB, we can help you find VisualGDB settings that will allow replicating the working setup. If it’s not working outside VisualGDB, you would need to find the most similar setup that works (e.g. another board), and iteratively compare the two setups until you find the root cause of the differences. This could be frustrating and time-consuming, but this is the way to go if you encounter problem spanning across many different components.

As for being experts, if we wanted to fully solve this problem, we would need to get the same board, same versions of the packages, reproduce the problem, and then try other combinations of Arduino packages, toolchains, ESP-IDF versions, etc., narrowing down the combination that causes trouble. It would take multiple hours (+ purchasing extra board) and would not result in any improvements to VisualGDB. The conclusion would be that a particular version of ESP-IDF doesn’t work well with a particular version of some library when using some particular combination of settings. And even that finding would be obsoleted when Espressif released another version of their package. If we offered this as a part of our regular support, we would have to raise the product prices several times to the point where very few users would be interested in it. So instead, we limit the included support to VisualGDB-specific issues (we have detailed page explaining it) and can gladly fix virtually anything else at our hourly consulting rate.

[support]

Hi,

VisualGDB looks for RTOS-specific symbols (tables of all tasks, etc) in the debugged image. As long as they are present, it automatically loads the RTOS plugin regardless of how the image was built.

Splitting the code into 2 images where RTOS and the actual payload is rather uncommon, so VisualGDB does not support this automatically. You can try using some external tool to merge them back into one ELF file and debug that one, but it could be tricky.

[support]

Hi,

Yes, they are only supported on ARM devices with background memory access. RISC-V is slowly becoming more popular, so we may eventually port the real-time analysis frameworks there, but currently they only work with ARM.

That said, Live Watch does not require any special frameworks and will work with any CPUs that support background memory reads.

[support]

Hi,

The GNU Make build system is very old, limited in many ways and does not support many advanced features directly. In theory, you should be able to get them working by patching the Makefiles, however we do not have any examples of it and are not planning to add one.

For new projects, please consider using Advanced CMake or MSBuild. Both work much better than plain GNU Make and have better integration on the VisualGDB side as well.

[support]

Hi,

It  looks like an issue between OpenOCD and a particular board. We do not know what is causing it – both the ESP32 OpenOCD port and the board are provided by Espressif.

Our best advice would be to first get it working via command line (i.e. being able to program FLASH on the same board with OpenOCD manually). When this works, we can help you configure VisualGDB to match the OpenOCD command line that worked.

[support]

Hi,

Please refer to this page for a detailed explanation of ESP-IDF integration and troubleshooting tips.

[support]

Our OpenOCD forks (including the fork of their fork) contain a couple of minor changes (e.g. commands for low-latency memory reading used by Live Watch and tracing), so we usually just apply those on top of the original sources from either fork, and rebuild everything. Without the sources, this won’t work.

Either way, you can manually just copy the binary from STM32CubeIDE on your side. It should work the same way.

[Author]

Posts