[support]

The Arduino-based projects are different from the regular ESP-IDF projects. They rely on the Arduino framework (using the rules in the ESP32 Arduino core) to build and program the project. Programming FLASH for Arduino projects is done via the COM port (same when using the Arduino IDE).

If the regular ESP-IDF projects work, you can use VisualGDB to develop them via the ESP-IDF project wizard (not the Arduino project wizard).

If you are getting different behavior between the regular ESP-IDF projects and Arduino projects, it is likely caused by differences between the ESP-IDF framework and the Arduino framework (that internally uses a different version of ESP-IDF and a completely different set of rules to build the code). Using VisualGDB on top of either ESP-IDF or Arduino will not change the way the underlying framework operates and will not eliminate the differences between these 2 frameworks.

[support]

Hi,

Please see this page for more details.

[support]

Hi,

Please find the answers to your questions below:

1. You can program the memory via COM port by right-clicking on the project in Solution Explorer and selecting “Program FLASH Memory“
2. You can prevent VisualGDB from programming FLASH memory during debugging via VisualGDB Project Properties -> Debug Settings -> Program FLASH Memory -> Never.

[support]

Sorry for the confusion, we will explain it below.

The latest stable VisualGDB version, that has fully passed all tests is 5.6r9 (build 4777).

The build 4807 is from our development branch (the latest build there is VisualGDB-5.6.109.4828.msi). This branch is updated very regularly, contains recently added features and fixes requested by our users, but has not fully passed all tests and might be less reliable than the official release.

We are currently finishing our work on the new tracing engine, that will first be published in the upcoming VisualKernel release, and will then make its way into VisualGDB 6.0 Beta 1. This Beta will include all the fixes from the development branch, including the one you mentioned. Until then, we would advise using the development build.

Substituting the build number would indeed get you the latest development build, however it normally shouldn’t be necessary, as the latest beta that will appear on the download page will include most of the recently added fixes.

[support]

We can point it out for you, however it would go through a different queue with a current turnaround of 2 business days. If you would like to get it done faster, please consider looking through the pages of VisualGDB Project Properties – most settings are placed very intuitively there.

[support]

Hi,

Visual Studio runs Clang as an external tool and applies the formatting instructions reported by it. This allows quickly switching between Clang versions, but has a few drawbacks, particularly when reformatting just one statement (e.g. when pressing ‘}’), and computing indentation for the new line.

VisualGDB uses a different approach – clang is integrated into our IntelliSense engine, so it continuously keeps a model of the current source file, and can apply more fine-tuned formats (and provide a GUI editor for formatting settings). The downside here is that switching to a newer clang requires updating our entire IntelliSense engine, and running extensive tests to ensure it won’t break any existing functionality.

We are currently finishing our work with the new tracing engine, that is being first released with VisualKernel (kernel traces generate huge volumes of data, so we use it to make sure the tracing engine is blazingly fast even under most heavy loads); updating the Clang engine to the latest LLVM/clang version is scheduled right after it.

[support]

Hi,

No problem and good to know it works. Feel free to submit merge requests via Github, or simply post them here or via the support form.

Also if you have further ideas about improvements we could do on our side, do not hesitate to share them with us.

[support]

This could be a bug in the Arduino framework, Espressif’s build of OpenOCD. You can try running OpenOCD and gdb manually to debug the same code – if the problem persists, the issue is caused by these tools, and using VisualGDB to launch them will not automatically fix the issue.

 

[support]

If the breakpoint is working, the FLASH should be programmed just fine (otherwise that code would never get executed).

If the LED is still not blinking, it’s something for you to figure out. All VisualGDB does is builds the code from the Arduino examples using Arduino build rules, and runs the result on the target using the ESP32 debugging tools. VisualGDB does not understand the code it is building/debugging and cannot fix it, or check that it makes sense for a particular target.

[support]

Hi,

This looks just fine. The program has been uploaded and started.  The errors shown by OpenOCD should not prevent it from working.

You can double-check it by setting a breakpoint inside loop() – it should trigger soon after the program has started.

That said, please make sure that you do not modify the original sample code in any way until you confirm that you can debug it. Changing some parameters (e.g. controlling JTAG pins directly) would indeed stop debugging from working.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

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.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

[support]

OK, we have looked into the way RTX manages its objects and it turns out it flags them in a special way inside the heap, so that the debugger can walk the heap blocks, determine the object types, and display their state.

We have updated our RTX plugin to show the following object types:

• Threads
• Timers
• Event Flags
• Mutexes
• Semaphores
• Memory Pools
• Messages
• Message Queues

The objects can be viewed via the RTX Objects view in Live Variables window:

As the RTX objects have many different fields and modes, we have made the layout customizable via an XML file. If you would like to pull some extra fields from the objects to the top-level view (above the [raw object] node), you can simply add the PromotedFields elements to it.

Please try the following build, it contains the updated plugin and the necessary interfaces: VisualGDB-5.6.109.4827.msi

Let us know if you have any further suggestions or encounter any issues. If you end up customizing the view by editing RTOSObjectTypes.xml, feel free to share your changes, and we will be happy to merge them on our side.

Attachments:

You must be logged in to view attached files.

[support]

Sorry about that. The new build came from our development branch that was recently updated to support the new built-in ARMClang assembler, and it looks like it was adding armclang-specific flags to the legacy armasm executable. We have fixed it in the following build: VisualGDB-5.6.109.4826.msi

[support]

Thanks, we have reproduced and fixed the problem. Indeed, the Keil compiler was reporting the array size in a slightly different format from the one expected by VisualGDB. Please try this build: VisualGDB-5.6.109.4825.msi

[support]

Hi,

Thanks for renewing your license.

This error happens because VisualGDB tries to use the shell executable on the target in order to pass some additional environment variables to gdb. The executable is likely broken, or named in an unexpected way, and this triggers the problem.

You can find out the exact command line used by VisualGDB via View->Other Windows->VisualGDB Diagnostics Console (you need to enable it, then reproduce the problem, then check the output for the full command line mentioning the gdb executable).

Once you find out the command line, please try running it manually via an SSH client, and ensure that you get the same error message. If you could share the exact command line you extracted, and more details about your system (e.g. the correct path of the tool referenced in the command line), we can help you configure VisualGDB to adjust it accordingly.

[Author]

Posts